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Abstract 

Although  recent  advances  in  graphics  workstations  promise  much  computing  power  For  the  future  needs  of 
rcscurcluTs,  traditional  approaches  to  software  organization  waste  much  of  this  power.  Most  systems  treat  the 
wurkstaticn  as  cither  a  fixed-function  terminal  or  a  self-contained  personal  computer;  these  rules  have 
limitations  that  can  be  overcome  by  considering  the  workstation  a  multi-function  component  of  a  distributed 
system.  I'raditional  standard  graphics  packages  and  object-oriented  window  systems  offer  important 
functionality,  but  a  third  approach,  virtual  terminal  management  systems,  is  more  appropriate  for  a 
distribu  tc  d  operating  system. 

'nic  Star, ford  Distributed  Systems  Group  has  implemented  such  a  distributed  system  for  graphics 
workstations,  organized  as  a  collection  of  servers  providing  services  to  clients.  Major  issues  arc  how  to 
partitior  functions  between  the  server  and  its  clients,  and  physically  partition  the  server.  In  particular,  the 
service  Utat  displays  graphical  objects  is  called  the  Virtual  Graphics  Terminal  Service  (VG'I'S).  ’nic  YG’IS 
architecture  is  described,  as  well  as  a  prototype  implementation. 

'Iliis  thesis  discus.scs  the  trade-offs  involved  in  partitioning  of  function  in  a  distributed  graphics  system. 
Fcrformancc  is  one  imporuint  property  traded  for  advanced  functionality  or  decreased  cost  'To  provide 
adequate  pcrfonnancc  in  a  distributed  system,  communication  costs  should  be  kept  low.  as  well  as  the 
frequency  of  tlie  communication.  Uy  providing  modeling  as  well  as  viewing  facilities,  the  VG’I'S  reduces  the 
communication  required  between  applications  and  the  service. 

Measurements  verify  that  performance  is  insensitive  to  network  bandwidth,  but  depends  heavily  on  CPU 
speed  and  protoc«>l  characteristics.  Using  stnicliirc  provides  imporiani  speed  improvements  in  some  eases, 
but  other  basic  factors  such  as  inner  loop  optimization  and  proper  batching  of  requests  make  even  larger 
differences. 

Finally,  conclusions  arc  drawn  regarding  the  partitioning  approaches  taken  in  the  VGI'S.  'The  VGTS  is 
suitable  for  a  large  class  of  applications  that  perform  graphics  as  an  aid  to  user  interface,  and  is  portable  to  a 
wide  range  of  powerful  worksuitions.  Moreover,  the  VG’I'S  can  be  used  as  a  basis  for  further  research  on 
many  open  questions  in  distributed  systems. 
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—  1  — 
Introduction 

When  computers  were  first  invented,  tlicir  time  was  so  valuable  that  elaborate  batch  systems  were  devised. 
People  would  spend  hours  preparing  commands  and  data  to  be  read,  processed,  and  printed  out  by  the 
computer.  In  die  l%0s  tlic  concept  of  timesharing  was  introduced,  dedicating  inexpensive  terminals  to  each 
user,  many  of  whom  shared  a  computer.  'I'hc  fust  timesharing  systems  were  modeled  after  batch  systems,  but 
soon  the  advantages  of  interactive  programming  became  worth  the  extra  cost.  Throughout  the  1970s  many 
computer  systems  were  designed  specifically  for  timesharing. 

Recent  advances  in  VLSI  technology  make  powerful  yet  physically  small  .and  inexpensive  computer  systems 
feasible.  Related  advances  in  network  technology  have  made  computer  systems  that  communicate  to  other 
systems  the  rule  rather  than  the  exception.  One  of  the  ideas  behind  timesharing  can  be  applied  with  today’s 
different  cost  constraints:  replicate  inexpensive  components  and  share  the  expensive  components. 

1.1  Graphics  Workstations 

I'hc  computing  resource  dedicated  to  each  single  user  is  called  the  workslaiion.  In  timesharing  systems  the 
workstation  is  just  a  fixed  flinction  terminal,  but  die  falling  cost  of  microprocessors  results  in  a  shift  to  more 
powerful  workstations.  For  the  rest  of  the  discussion  we  will  assume  that  the  workstation  contains  some  kind 
of  programmable  priKcssor,  some  memory,  at  least  one  display  device,  and  at  least  one  input  device. 
Workstations  arc  often  connected  in  clusters,  forming  a  workstation-based  distributed  system,  as  illustrated  in 
figure  1-1. 

The  advent  of  high-performance  graphics  workstations  has  been  a  mixed  blessing.  Inexpensive 
microprO'Cessors  seem  to  promise  unlimited  eomputing  power  to  satisfy  everyone's  needs.  However,  now  that 
the  information  being  processed  and  viewed  is  becoming  more  valuable  than  die  hardware  doing  the 
processing,  old  techniques  for  organizing  computing  systems  arc  no  longer  valid.  In  particular,  common 
activities  like  information  display  often  have  processors  dedicated  to  them,  but  still  require  access  to  other 
computing  resources. 

Although  dicy  arc  interconnected,  most  workstation  systems  built  to  date  continue  to  treat  the  workstation 
solely  as  a  fixed-function  terminal  or  a  self-contained  personal  computer.  More  interesting  roles  exist 
between  these  two  extremes,  especially  considering  die  next  logical  step  in  the  organization  of  computing 
systems:  many  computing  elements  per  user  cooperating  on  die  same  task.  'To  accomplish  diis  cixiperation, 
the  tasks  must  be  partitioned  or  divided  at  appropriate  points  depending  on  many  factors.  This  thesis 
attempts  to  investigate  and  charactcri/.e  some  experimental  attempts  at  partitioning  in  a  distributed  graphics 
system.  The  goal  is  not  a  system  that  solves  all  the  problems  of  distributed  graphics,  but  rather  to  design  and 
build  a  prototype  that  can  be  used  to  evaluate  one  approach. 

1 .2  Role  of  the  Workstation 

It  is  fairly  certain  that  both  computing  power  and  communication  capability  will  become  more  pervasive  in 
the  future,  and  these  trends  will  continue  for  some  time.  At  present,  however,  die  bottleneck  in  the 
development  of  network-based  systems  has  become  die  software,  with  much  of  the  potential  of  powerful 
workstation  hardware  being  unrealized.  The  first  key  problem  is  to  find  the  appropriate  role  for  the 
workstation  within  the  context  of  the  whole  system.  There  arc  three  basic  approaches  to  the  role  of  graphics 
workstations  in  a  computing  environment:  as  a  terminal,  as  a  personal  computer,  and  as  a  component  of  a 
distributed  system. 
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Figure  1-1:  A  worksuition-boscd  distributed  system 


1 .2.1  The  Workstation  as  Terminal 

When  a  low  performance  workstation  is  used  wiUi  a  timesharing  system,  it  is  convenient  to  treat  the 
workstation  as  a  temiinal  [91].  Hiis  concept  applies  not  only  to  traditional  alphaniiineric  tenninals,  but  also  to 
bitmap  (called  “all  points  addrcss;iblc"  by  IIJM)  displays.  Uilinap  displays  contain  an  area  of  memory  which 
stores  every  pixel  of  the  displayed  image.  T  he  advantages  of  using  graphics  terminals  with  timesharing 
systems  has  been  rccogni/.cd  for  many  years,  but  tlie  cost  of  tJic  ncccs.sary  display  hardware,  compute  power, 
and  communications  bandwidth  has  been  prohibitive  until  recently  [70]. 

One  of  the  first  graphics  worksUitions  with  local  network  capability  was  the  Alto,  designed  and  built  by  the 
Xerox  Palo  Alto  Research  Center  (PARC)  (142).  Ilic  ADIS  System  |127|,  tlic  Alto  Temiinal  Program  [12], 
and  IX:utsch's  Remote  IlitHlt  prokKol  [47]  were  developed  to  allow  programs  on  a  timesharing  system  to  use 
an  Alto  as  a  display  device  across  a  network,  i  fowever,  in  each  of  these  protocols  all  but  the  lowest  level 
viewing  operations  were  done  on  one  particular  host,  with  the  workstation  only  manipulating  biunaps.  'Iliis 
was  due  to  the  limited  speed  and  main  memory  capacity  of  the  Alto,  designed  in  the  v.arly  1970s.  Since 
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current  workstations  have  faster  processors  and  larger  memories,  new  architectures  should  take  advantage  of 
this  increased  power. 

Bell  Lab's  Layers  System  [105]  for  the  Blit  terminal  [72],  now  called  the  Teletype  5620,  provides  a  similar 
bit*map  interface  to  tlie  application.  An  application  can  run  on  the  terminal  and  communicate  to  a  (single) 
host  using  a  higher-level  protocol.  Unfortunately,  these  protocols  arc  not  standardized,  and  the  layers  system 
is  only  designed  for  one  particular  kind  of  workstation  to  communicate  with  one  kind  of  operating  system. 
Since  many  users  arc  only  concerned  with  one  operating  system  or  one  terminal,  these  systems  may  be 
successful.  In  fact,  the  ability  to  act  as  a  terminal  is  an  important  capability  that  should  be  included  in  any 
workstation-based  system.  However,  even  tlic  designers  of  the  I.aycrs  system  arc  working  on  a  more  flexible 
approach  that  does  not  waste  the  power  of  more  advanced  workstations. 


1.2.2  The  Workstation  as  Personal  Computer 

For  higher  performance  workstations,  one  popular  approach  is  to  construct  a  small  model  of  a  larger 
timesharing  system.  This  is  a  simple  and  powerful  idea  pioneered  by  the  Alto  computer  at  Xerox  PARC,  and 
now  adopted  in  many  new  products.  Hxampics  include  the  various  Lisp  Machines  [16],  the  Perq  [144],  and 
many  other  new  commercial  systems  being  announced  weekly  at  die  time  of  this  writing. 

One  principle  motivation  behind  the  personal  computer  approach  is  to  avoid  the  partitioning  problem,  and 
instead  offer  a  single  “integrated"  system.  But  in  reality  each  personal  computer  is  isolated,  resulting  in  a 
highly  partitioned  system  with  the  following  practical  problems; 

•  Cost:  There  arc  economics  of  scale  involved  in  devices  such  as  disks.  For  example,  30  10  Mbyte 
disks  cost  much  more  than  a  single  300  Mbyte  disk.  A  moderately  sized  disk  would  essentially 
double  the  current  cost  of  the  workstation.  Typically  configured  Lisp  Machines  sell  for  SIOO.CXX) 
to  $200,000.  Since  many  organizations  do  not  have  $1000  terminals  for  each  member,  they 
certainly  will  not  spend  200  times  that  amount  fora  single  user. 

•  Reliability:  An  office  environment  is  not  as  controlled  as  a  clean,  air-conditioned  machine  room. 
Preventive  maintenance  and  repair  of  delicate  mechanical  equipment  is  much  easier  for 
centralized  facilities. 

•  Flexibility:  The  personal  computer  model  provides  for  rigid  control  on  tlie  number  of  users;  if 
you  are  not  one  of  the  few  who  own  one,  or  find  one  to  share,  you  can  not  use  any  computing 
resources  during  peak  hoars. 

•  Performance;  There  arc  two  aspects  of  performance.  Although  fast  response  to  user  interaction 
(such  as  editing  [57])  favors  pci'sonal  computing,  high-throughput  and  low-interaction  activities 
(such  as  compilation)  favor  large  shared  proccs.sors. 

•  Comfort:  Adequately  sized  disks  arc  large  and  noisy,  producing  an  unwelcome  intrusion  into  the 
office  environment,  with  as.s»x;iated  power  requirements  and  heat  dissipation  prtrhiems.  For 
example,  the  Xerox  lltM)  I  isp  workstatUms  at  Stanford  are  physically  centralized,  with  only  the 
displays  and  keyboards  outsiile  the  machine  OKim. 

•  Duplication:  Many  of  the  files  on  each  disk  arc  duplicated.  This  obviously  wastes  space,  but 
more  importantly,  it  causes  problems  with  propagation  of  updates  and  useless  duplication  of 
sofiwarc  maintenance  effort 

'Iltcrc  will  still  be  many  commercially  successful  personal  computer  products,  l-or  example,  the  entire 
Unix  [111]  operating  system  has  been  ported  to  a  worksuuion  with  a  liK-al  disk  interfitec  for  each 
workstation  [68, 118].  Reasons  frrr  this  success  include  the  value  many  people  put  on  total  control,  and  the 
"personal"  nature  of  much  computing  [1 16].  For  instance,  a  small  business  would  probably  initially  prefer 
one  self-contained  personal  computer. 
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However,  if  tliat  business  outgrows  the  single  personal  computer,  and  wishes  to  share  large  distributed 
databases,  the  problems  described  here  will  eventually  arise.  Except  for  the  low-performance  computers 
purchased  for  home  use,  most  so-called  “personal”  computers  used  for  science  and  busness  are  actually 
purchased  by  some  group  or  department,  and  arc  therefore  actually  shared.  Furthermore,  the  high  cost  of 
these  scientific  workstations  has  limited  shipments  to  only  a  few  thousand  units  [1S3].  For  larger,  multi- 
person  projects  that  arc  performed  in  research  and  development  environments,  small  self-contained  systems 
arc  not  always  desirable. 

Even  if  workstations  arc  available,  current  researchers  still  heavily  use  centralized  server  hosts.  The 
following  arc  some  reasons  it  might  not  be  possible  or  desirable  to  run  all  applications  on  the  workstation: 

•  The  application  may  require  fast  floating  point  hardware. 

•  Tlie  application  may  require  large  virtual  or  physical  memory. 

•  The  application  may  require  frequent  access  to  a  large  database. 

•  The  application  may  be  written  in  a  particular  language  or  dialecL 

•  The  application  may  require  a  license  to  run  on  each  different  CPU. 

•  llic  application  may  access  secure  information  that  should  not  be  transmitted  over  a  network. 

•  The  application  may  perform  I/O  directly  to  a  particular  device. 

•  The  application  may  contain  dependencies  on  a  particular  machine  or  operating  system. 

Even  if  the  necessary  resources  are  available  as  an  option  for  the  workstations,  they  arc  often  too  expensive  for 
widespread  use. 

One  could  argue  that  since  hardware  costs  arc  decreasing,  the  personal  computer  model  will  inevitably 
dominate  in  tlic  end.  But  the  decrease  in  hardware  costs  means  that  software  costs  become  relatively  more 
important  (IStiJ.  It  is  well  known  that  the  largest  portion  of  software  life-cycle  costs  goes  to  maintenance  [18], 
llicrcforc,  case  of  software  maintenance  should  be  an  important  issue  in  evaluating  a  computing  system 
architecture.  With  individual  personal  eomputers,  all  users  have  to  do  their  own  software  maintenance.  1his 
results  in  a  potentially  enormous  increase  in  the  costs  asstKialed  with  distributing  and  installing  new  versions 
of  software. 

Even  considering  tmly  hardware  costs,  self-contained  personal  computers  may  eventually  become  more 
expensive  than  other  alternatives.  One  might  reason  that  since  memory  costs  arc  decreasing,  and  memories 
arc  getting  more  dense,  the  trend  will  be  to  computer  systems  with  higher  ratios  of  memory  to  processing 
power.  However,  a  typical  computer  ten  years  ago  was  an  IBM  Systcm/370  with  about  a  million  bytes  of 
physical  memory  |I04].  Today,  a  representative  computer  is  tlic  IBM  PC.  with  almost  half  tltc  processing 
speed,  but  only  one  tenth  as  much  memory,  typically  about  lOOK  bytes  [54J.  Of  course  tlie  lower  price  of  the 
PC  means  that  many  more  |Koplc  can  alVord  one.  On  tlie  other  hand,  the  organi/iition  tliat  ten  years  ago  had 
a  370/138,  can  now  alTord  a  machine  with  a  proces.sor  about  eight  times  faster  and  sixteen  times  as  much 
memory.  I  .arge  computers  are  expanding  principally  by  adding  memory,  while  smaller  computers  arc  getting 
less  expensive  principally  by  keeping  memory  small. 

More  interesting  evidence  is  the  relative  price  of  mcmtirics  and  processors.  1'oday  an  MC68000  processor 
costs  about  $50.  and  a  64K  bit  memory  chip  costs  about  $S.  'Hius,  if  a  system  has  mure  than  about  ten 
memory  chips  per  prtxrcssor  chip,  the  memory  cost  will  dominate.  Since  the  cost  to  prtxlucc  integrated 
circuits  in  large  quantities  depends  mostly  on  packaging  considerations  such  as  tlie  number  of  pins,  tlie  ratio 
of  prtKCSsor  to  memory  cost  will  probably  stay  fairly  low.  'Iliis  provides  motivation  to  design  computer 
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systems  that  take  advantage  of  low-cost  pnx^essors  by  replicating  them  for  each  user,  but  share  expensive 
resources  such  as  memory. 


1.2.3  The  Workstation  as  a  Component  of  a  Distributed  System 

Since  most  researchers  who  use  personal  computers  quickly  recognize  the  problems  caused  by  isolation, 
manufacturers  usually  provide  some  form  of  communication  capability.  For  example,  a  file  transfer  program 
may  be  used  to  transfer  files  eitlier  explicitly  or  semi-automatically  between  the  personal  disks.  Other 
approaches  use  a  remote  disk  or  logical  file  system  to  intercept  operations  at  die  appropriate  level,  and  route 
them  instead  to  a  remote  disk  or  file  access  user  module.  Ibere  are  many  practical  reasons  to  eliminate 
expensive  components  such  as  secondary  storage  from  each  workstation.  A  diskless  workstation  is 
inexpensive,  small,  quiet,  and  has  almost  no  moving  parts  to  break. 

Several  efforts,  such  as  Locus  at  UCLA,  modified  standard  operating  systems  to  allow  shared  and  replicated 
file  systems  [150].  lierkeley  4.2  Unix  was  intended  for  diskless  operation,  aldiough  for  performance  reasons 
most  4.2  systems  still  have  local  disks,  and  alt  programs  still  run  on  the  workstation  [68].  Some  attempts 
extend  timesharing  systems  to  handle  remote  execution  [S3],  but  a  more  comprehensive  solution  is  needed. 
The  file  service  abstraction,  developed  in  projects  such  as  Woodstock  [137],  can  be  generalized  into  the  server 
model,  resulting  in  more  flexibility  of  interconnection. 

1.2. 3.1  The  Server  Model 

'llic  architecture  to  be  presented  in  Chapter  3  treats  the  workstation  as  a  multi-fimction  component  of  a 
distributed  system.  We  do  not  waste  its  power  by  treating  it  solely  as  a  terminal,  nor  do  we  isolate  it  from  the 
rest  of  the  world,  under  the  false  assumption  that  it  can  be  all  things  to  all  users.  Rather,  by  supporting  a 
distributed  operating  system  the  \yorkstation  may  perform  any  function  best  suited  to  the  user,  the  hardware, 
and  die  applications  at  hand  [79, 86, 109,  ISS]). 

In  this  view,  die  operating  system  is  just  a  collection  of  servers,  and  a  way  of  accessing  those  servers.  An 
implementation  of  this  model  usually  consists  of  cooperating  kernels  providing  an  inter-process 
communication  system,  and  services  implemented  as  proces.ses'.  Ilie  kernel  of  a  server-based  operating 
system  acts  analogously  to  a  hardware  bus,  being  essentially  a  communications  switch.  In  addition  to  the 
physical  wires  used  to  connect  modules  in  a  hardware  bus.  a  standard  protocol  is  agreed  upon  to  define  the 
semantics  of  the  communication.  Similarly,  in  our  software  model,  in  addition  to  the  ability  to  send  message, 
a  protocol  is  defined  for  the  meaning  of  the  mess^cs. 

'Iliis  model  does  not  make  the  system  versus  user  distinction:  the  design  is  in  terms  of  “clients”  which 
invoke  tlie  services  of  a  particular  server.  For  example,  the  concepts  of  "terminal”  and  “personal  computer” 
are  now  merely  roles  played  by  some  collection  of  proccs,scs  and  processors  at  any  given  time.  ITie  result  is 
much  more  flexibility  in  the  partitioning  of  the  resulting  system. 

1.2. 3. 2  Network  Transparency 

Uy  considering  the  workstation  as  a  component  of  a  distributed  system,  we  could  consider  a  single 
underlying  communication  concept  for  “network  transparency.”  In  general,  network  transparency  is  a 
worthwhile  goal:  programs  should  be  as  independent  as  possible  of  tlie  location  of  tlicir  execution  and  the 
resources  tliey  use.  However,  every  system  has  a  boundary  on  this  transparency,  so  die  problem  of 
communicating  to  the  outside  tliis  boundary  must  be  addres.scd  eventually.  In  fact,  all  the  computing 
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resources  in  the  world  can  be  considered  a  single  computer  system,  with  many  disconnected  components. 
'Iliis  motivates  communication  between  various  kernels  which  may  have  vastly  different  underlying 
communication  concepts,  resulting  in  what  might  be  called  a  distributed  kernel.  Network  communication 
always  has  some  cost  associated  with  it,  so  perfect  transparency  is  never  possible  with  respect  to  performance. 
Chapter  3  describes  a  system  which  has  been  developed  to  help  address  some  of  these  issues. 


1.3  Kinds  of  Partitions 

I'hc  hardware  trends  discussed  in  the  previous  sections  result  in  a  physically  distributed  computing  system, 
with  a  corresponding  partition  required  of  the  software.  'Phere  are  several  forms  that  partitioning  can  take, 
some  of  which  arc  introduced  below. 


1.3.1  Physical  Partitions 

Computations  can  always  be  done  more  efficiently  on  machines  that  arc  built  specifically  for  a  particular 
purpose.  For  example,  a  machine  with  large  and  fast  disks  is  needed  for  fast  searching  of  databases,  while 
interacting  with  a  user  requires  powerful  graphics  capability.  'Phis  suggests  a  physical  partitioning  by  putting 
particular  operations  onto  specially  built  machines. 

Partitioning  has  a  long  history  in  the  field  of  computer  graphics.  Due  primarily  to  the  high  cost  of 
hardware,  graphics  systems  of  the  1960’s  consisted  of  relatively  powerless  graphics  devices  connected  directly 
to  relatively  large-scale  computers,  either  single-user  or  time-shared.  However,  as  the  graphics  devices 
became  more  sophisticated,  the  load  on  timeshared  hosts,  in  particular,  became  insufferable. 

Fortunately,  the  minicomputers  of  the  1970s  led  to  satellite  graphics  systems  that  served  to  offload  a 
variable  amount  of  graphics  functions  on  to  another  machine  [SI,  55, 62, 148].  By  judicious  partitioning  of 
responsibility  between  the  host  and  the  graphics  device,  it  was  possible  to  achieve  both  better  response  and 
higher  throughput.  Ilic  more  powerful  the  graphics  processor,  the  more  flinctions  that  could  be  offloaded, 
until  the  satellite  system  took  on  die  appearance  of  the  host.  Taken  to  its  extreme,  this  branch  of  evolution 
led  naturally  to  the  personal  computer  -  completing  a  round  on  the  Wheel  of  Reincarnation  [101],  as 
illustrated  in  l-igurc  1-2. 

In  configuration  1  of  Figure  1-2,  the  prtKcssor  directly  controls  the  display  device.  In  configuration  2,  the 
display  commands  arc  accessed  directly  from  the  processor’s  memory.  In  configuration  3,  a  special  dual-port 
memory  hold  the  display  commands.  In  configuration  4,  a  second  pnxrcssor  has  been  added  to  send 
commands  to  the  display  from  the  display  buffer.  'I'hc  display  control  is  similar  to  configuration  1,  except  for 
die  communication  channel  to  the  main  CPU.  At  each  step  through  this  cycle  die  partionability  problems 
must  be  addressed.  In  fict,  the  amount  of  distribution  of  function  increases  at  each  cycle. 

For  die  1980’s,  increasingly  powerful  worksUitions.  together  with  the  proliferation  of  networks,  have  made 
truly  dislribulcd  graphics  possible.  'Ilic  higher  bandwidth  of  available  networks,  when  compared  to  that  of 
previous  host-satellite  interconnections,  makes  it  even  more  feasible  to  achieve  better  performance  by 
partitioning  die  application  between  machines,  especially  if  die  remote  host  is  significantly  more  powerful 
dian  die  Ux'al  workstation.  Moreover,  it  is  now  pos.sible  for  a  single  workstation  to  have  access  to  muldple 
backend  machines,  possibly  simultaneously.  Many  of  those  machines  may  support  graphical  applications  that 
can  not  be  executed  on  the  workstation  -  due  to  memory  or  language  requirements,  fur  example  -  but  can  use 
die  workstation  for  output 

On  a  hardware  level,  a  given  computer  system  may  contain  several  different  processors,  and  even  a  single 
priKCSSor  may  be  implemented  as  several  functional  units.  'This  is  consistent  with  further  travel  on  die  Wheel 
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Figure  1-2:  The  wheel  of  reincarnation 

of  Reincarnation  model  cited  above.  These  parallel  architectures  provide  much  promise  for  the  future,  but 
this  thesis  will  concentrate  on  partitioning  at  higher  levels,  before  experimenting  with  partitioning  problems 
into  many  pieces  (which  will  be  required  by  future  hardware),  we  should  have  a  good  understanding  of  how 
to  partition  them  into  two  pieces. 


1.3.2  Logical  Partitions 

In  addition  to  the  physical  partitioning  that  may  be  motivated  by  cost  and  performance,  experience  in 
developing  Iwal  area  networks  by  the  author  has  resulted  in  the  rcaliz;>lir)n  tliat  long  before  networks  reach 
their  physical  size  limits,  lliey  usually  become  unmanageable  once  they  span  several  bureaucratic  boundaries. 
Fven  if  the  network  is  physically  contiguous,  artificial  division  along  organizational  lines  is  often  desired. 

There  is  also  a  more  fundameiUal  logical  partitioning  between  graphics  systems  and  tlie  application 
program.  That  is.  system  designers  must  determine  which  fiicilitics  tlic  graphics  system  simuld  provide  and 
which  the  application  should  provide.  Similarly,  even  when  the  fimetions  of  the  service  arc  decided  upon,  the 
server  may  be  implemented  in  many  ways  by  partitioning  its  functions  between  modules  or  prwesses,  for 
example. 


1.3.3  Static  and  Dynamic  Partitions 

Another  attribute  of  tJie  partition  is  when  it  is  performed.  A  static  partitioning  is  performed  once  when  the 
program  is  designed,  configured,  or  initialized.  More  ambitious  projects  might  try  to  partition  dynamically 
during  run-time.  I^ad  sharing  is  the  usual  motivation  for  dynamic  partitioning.  'Utis  involves  migrating  tasks 
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to  more  evenly  distribute  the  load  among  several  computer  systems.  Load  sharing  can  be  used  only  when  the 
systems  are  relatively  homogeneous.  In  this  work  we  will  deal  with  heterogeneous  systems  consisting  of 
dedicated  workstations  and  centralized  server  hosts. 

There  have  been  a  few  attempts  at  dynamic  partitioning  in  heterogeneous  systems,  by  assigning  tasks  to 
either  the  mainframe  or  host  depending  on  current  workloads.  For  instance,  die  iCOi>S  system  at  Brown 
University  attempted  to  perform  dynamic  partitioning  [146, 128].  One  application  using  the  Brown 
University  Graphics  System  (UUGS)  was  dynamically  distributed  between  a  mainframe  and  a 
minicomputer  [97].  In  another  example,  the  CAGI5  system  at  the  University  of  North  Carolina  automatically 
generated  the  linkages  at  compile  time  for  distributed  graphics  programs  written  in  Pi./l  [62],  More 
interesting  would  be  a  solution  to  the  problem  of  handling  multiple  applications  or  multiple  languages 
simulUmcously. 

We  shall  see  enough  problems  with  static  partitioning  that  it  is  not  clear  if  dynamic  partitioning  is  worth  the 
cost.  In  cither  case,  efficient  techniques  for  static  partitioning  and  effective  measurements  and  evaluations  are 
prerequisites  to  solving  the  more  general  problem.  Without  the  ability  to  easily  experiment  with  static 
partitioning,  dynamic  partitioning  should  not  even  be  attempted. 


1 .3.4  Total  and  Partial  Partitions 

Unfortunately  the  word  “partition”  has  taken  on  a  fairly  specific  meaning  in  the  terminology  of  networks. 
It  usually  refers  to  a  single  network  that  is  divided  into  two  or  more  totally  disconnected  smaller  subnetworks 
because  of  a  failure  of  one  or  more  components.  A  typiail  example  of  this  kind  of  partitioning  involves  the 
failure  of  several  links  or  a  gateway,  causing  a  network  to  divide  into  disconnected  parts.  It  is  desirable  to 
continue  functioning  as  much  as  possible  within  each  network  partition. 

However,  if  the  disconnected  subnetworks  never  reconnect,  then  the  problems  arc  just  the  same  as  those  of 
several  smaller  networks  in  isolation,  'fhe  interesting  situations  occur  only  when  tlic  parts  arc  reconnected, 
and  information  Hows  again  between  the  parts.  Hxpcrlcncc  with  tlic  Stanford  University  Network  has  been 
that  in  reality  slow  or  partial  degradation  is  much  more  common  than  total  failure. 

This  thesis  concerns  itself  only  with  the  information  flow  between  the  parts  of  a  connected  system,  not  the 
details  of  recovery  from  link  errors  after  total  partitions.  A  partial  partitioning,  in  which  communication 
between  the  parts  is  possible  but  more  costly  than  communication  within  each  part  may  be  incviuiblc  or  even 
desirable.  Additional  reasons  for  this  will  be  discussed  in  in  Chapter  S.  in  particular  tlic  sections  on  future 
computing  system  organizations. 


1.3.5  Protocol  Design:  the  Result  of  Partitions 

Many  critical  choices  must  be  matle  when  designing  the  protocols  or  intcrfiiccs  between  the  parts  of  a 
distributed  system.  The  protocols  should  Ik  at  a  high  enough  level  to  make  the  communication  cITicient  but 
flexible  enough  to  allow  for  most  users’  needs.  The  designer  must  anticipate  the  degree  of  functionality  tJiat 
users  will  want,  and  provide  enough  services  to  achieve  that  functionality,  or  else  the  system  will  be  too 
restrictive  to  use.  At  the  same  time,  if  the  service  provides  too  many  features,  or  requires  too  much  interaction 
with  the  client,  the  performance  will  not  be  adequate.  'Hiis  diesis  evaluates  the  protocol  choices  made  in  one 
design  of  a  distributed  graphics  system. 
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1.4  Overview  and  Major  Contributions 

The  spcctmm  of  roles  for  graphics  workstations  from  fixed-function  terminal  to  self-contained  personal 
computer  was  examined  in  this  chapter,  along  with  motivations  for  the  study  of  the  partitioning  problem  for 
distributed  graphics  systems.  The  next  chapter  discusses  tlirce  different  approaches  to  related  problems: 
traditional  standard  graphics  packages,  object-oriented  window  systems,  and  virtual  tenninal  management 
systems.  Chapter  3  presents  the  Virtual  Graphics  Terminal  Service  architecture  in  fairly  abstract  terms.  In 
particular,  the  protocol  between  the  server  and  a  client  application  program  is  specified.  Chapter  4  describes 
a  prototype  implementation  of  the  Virtual  Graphics  'I’erminal  Service,  the  VGTS  user  interface,  and  a  sample 
application  program.  Chapter  5  investigates  some  issues  involved  in  partitioning  of  fimetion.  the  rationale 
behind  the  choices  made  in  the  VGTS  design,  and  some  simple  performance  models  to  motivate  experiments. 
Chapter  6  gives  the  results  of  tlicse  measurements,  and  discusses  the  cost/pcrformance  tradeoffs,  l-'inally, 
some  conclusions  and  directions  for  future  work  arc  drawn  in  Chapter  7. 

Although  many  people  were  involved  in  the  development  of  the  VGTS,  this  thesis  concentrates  on  tlie 
following  major  research  contributions  by  tlie  author: 

1.  The  virtual  terminal  concept  was  extended  to  support  graphics  by  incorporating  support  for 
structured  display  files,  as  well  as  conventional  textual  interaction.  The  abilities  of  virtual 
terminals  to  support  multiple  distributed  applications  arc  combined  with  the  power  and 
portability  of  structured  display  files. 

2.  The  application  interface  for  defining  graphical  objects  was  specified  and  implemented  separately 
from  the  user  interface  for  viewing  those  objects.  Both  the  advantages  and  disadvantages  of  this 
strict  separation  are  discussed. 

3.  The  protocol  used  for  defining  objccLs  was  extended  transparently  across  networks  using  several 
transport  protocols,  resulting  in  distributed  graphics  programs,  ’lltcsc  programs  were  actually 
used,  so  performance  constraints  were  stringent 

4.  Measurements  were  performed  to  determine  the  effect  of  various  factors  on  performance  of 
graphical  applications.  The  measurements  verify  that  performance  is  insensitive  to  network 
bandwidth,  but  depends  heavily  on  CPU  speed  and  protocol  chanKtcristics.  Using  structure 
provides  important  speed  improvements  in  some  cases,  but  other  basic  factors  such  as  inner  loop 
optimization  and  proper  batching  of  requests  make  even  larger  differences. 

Tlie  results  show  tliat  tlie  VGTS  is  suiuible  for  a  large  class  of  applications,  and  can  be  used  as  a  basis  for 
much  further  research. 
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—  2  — 
Related  Work 

This  chapter  compares  the  evolution  of  three  separate  kinds  of  systems  related  to  distributed  graphics,  as 
illustrated  in  Figure  2-1.  'llie  arrows  in  this  F'igure  arc  drawn  in  tlic  direction  of  control  flow.  'I'he  first  and 
oldest  line  of  development  is  the  traditional  suindard  graphics  package,  with  tlic  application  programmer  in 
control  over  a  graphics  library.  The  second  deals  with  so-called  “object-oriented  window  systems”  for 
personal  worksUitions  with  die  user  in  ultimate  control.  F'inally.  a  third  concept,  virtual  terminals,  combines 
both  other  approaches,  with  the  user  in  control  of  the  viewing  prtx:css  while  die  applications  control  the 
objects  being  displayed. 


Applications 


Terminal  User  Terminal 

User  Terminal 


a)  Traditional  standard  b)  Object-oriented  c)  Virtual  terminal 

graphics  packages  window  systems  management  systems 

Figure  2- 1 :  ITirce  kinds  of  approaches 

2.1  Standard  Graphic?  Packages 

It  is  important  to  examine  die  long  history  of  Computer  Graphics  to  discover  what  functionality  has  been 
detennined  U)  be  important.  Although  many  cITorLs  have  involved  ad  hoc  systems  to  produce  a  particular 
picture  or  support  a  particular  device,  several  sUindard  efforts  are  more  promising  for  our  needs.  Although 
wc  are  concerned  with  distributed  systems  for  workstations,  standards  have  die  advanuigc  of  making  graphics 
software  more  readily  available.  Standards  sluuild  also  be  studied  so  die  common  concepts  and  terminology 
can  be  developed  to  compare  dilTerent  approaches. 

larly  graphics  systems  were  usually  “packages"  of  funclions  called  by  application  programs,  llie  few 
dominant  manufacturers  of  graphics  devices,  such  as  Calcomp  and  I'cktronix.  established  dc  facto  sLindards 
until  the  1970s  (76 j.  Users  first  would  link  a  program  with  die  appropriate  object  library.  When  die  program 
was  executed  it  would  read  some  input  data  and  produce  output  through  the  graphics  functions.  Since 
graphics  devices  were  expensive,  a  package  was  usually  concerned  with  one  kind  of  device.  If  the  user  wanted 
output  on  another  device,  either  the  program  could  be  linked  with  another  version  of  the  graphics  library,  or 
die  library  would  handle  several  possible  graphics  devices  at  run-time. 

nicsc  types  of  graphics  systems  arc  most  common  since  they  have  been  in  use  for  many  years,  and  thus  arc 
the  subject  of  many  standardization  efforts.  Figure  2-2  gives  an  overview  of  the  interfaces  between 
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components  of  traditional  graphics  packages.  At  ttic  highest  level  arc  application  databases  where  models  arc 
stored.  One  standard  database  format  is  called  iGi-5  for  Initial  Graphics  Hxchange  Standard  [3).  This  is  a 
common  database  format  to  allow  a  user  to  exchange  computer  aided  design  data  between  systems  of 
different  manufacturers. 


w 


Application 

Database 


Figure  2-2:  Standard  graphics  package  interfaces 


The  application's  interface  to  the  graphics  system  has  seen  die  largest  amount  of  standardization,  witlt  many 
similar  but  incompatible  standards  for  this  level  such  as  GKS.  CORE,  PlliGS.  and  others,  to  be  described  in  the 
remainder  of  this  section.  Some  attempts  at  lower  levels  of  standardization  include:  Vl)l,  between  the 
graphics  system  and  the  device  driver,  and  NAPi  re,  between  the  device  driver  and  the  device. 


2.1 .1  The  SIGGRAPH  CORE  Graphics  System 

llic  ACM  Special  Interest  Group  on  Graphics  (siGGKAl’ll)  Graphics  Suindards  Planning  Committee 
report,  commonly  known  as  CoRi:.  has  become  widely  used  as  a  model  for  graphics  systems  (147).  One  major 
motivation  for  tliis  standardiziition  attempt  was  the  undesired  distinction  made  at  tliat  time  between  directed 
beam  (vector  refresh)  graphics  devices,  and  storage  tube  (and  hard  copy)  devices.  'ITic  importance  of  device 
independence  was  emphasized  at  the  1976  Computer  Graphics  workshop  in  Scillac,  France  (60).  This 
workshop  attempted  to  unify  the  treatment  of  the  two  kinds  of  graphics  devices,  and  formed  a  basis  for  many 
subsequent  graphics  packages  such  as  CORE. 


RIXATI-D  WORK 


15 


2. 1.1.1  Device  Independence 

Hard  copy  and  storage  tube  devices  have  a  simple  physical  concept  of  a  current  location.  For  example,  in  a 
pen  plotter  the  location  of  the  pen  was  obviously  visible.  A  sequence  of  move  and  draw  commands  was  the 
most  natural  way  to  think  of  how  a  pen  plotter  created  a  picture.  The  CORF,  system  extended  tJiis  move  and 
draw  concept  to  tliree  dimensions,  using  a  synthetic  camera  analogy.  Other  state  information  such  as  the 
color  or  size  of  the  pen,  was  also  extended  into  tlic  CORI-  system.  The  application  constructed  a  model  of  the 
object  in  its  own  internal  data  stmctiircs,  and  would  use  the  graphics  package  only  for  viewing  operations. 

On  the  other  hand,  directed  beam  graphics  devices  usually  had  display  lists,  which  were  traversed 
repeatedly  to  display  the  picture.  Changing  one  clement  in  tlic  display  list  would  instantly  change  the  item 
being  displayed,  while  storage  tube  and  hard  copy  devices  would  be  erased  and  redrawn  completely  for  any 
modifications  besides  additions.  Cork  used  the  concept  of  segment  to  represent  this  retained  graphics 
information. 

2.1 .1 .2  Coordinate  Systems 

Another  important  contribution  of  CORF  was  the  understanding  of  the  importance  of  different  coordinate 
systems.  The  CORi;  System  and  most  other  subsequent  graphics  packages  deal  with  tlircc  coordinate  systems: 

1.  World  Coordinates  (WC)  arc  arbitrarily  defined  by  the  applications  programmer.  In  CORF  these 
arc  floating  point  numbers  in  citlier  two  or  tlircc  dimensions. 

2.  Normalized  Device  Coordinates  (NDC)  are  used  to  define  a  uniform  coordinate  system  for  all 
display  surfaces.  In  CORF  these  arc  two  dimensional  floating  point  numbers  between  z.cro  and 
one. 

3.  IXivicc  Coordinates  (DC)  represent  the  actual  units  used  by  the  display  device,  usually  unsigned 
integers  of  ten  to  sixteen  bits. 

Corf,  implementations  map  from  world  coordinates  to  normalized  device  coordinates,  with  a  driver  for  each 
device  mapping  from  normalized  device  coordinates  to  actual  device  etwrdinates.  This  allows  most  of  the 
graphics  package  implementation  to  be  retained  when  new  graphics  devices  arc  introduced. 

2.1 .1 .3  CORE  as  a  Standard 

The  Corf:  System  was  defined  as  a  set  of  language-independent  functions,  with  the  mapping  from  the 
abstract  function  names  to  programming  language  idenlifici's  left  undefined.  This  resulted  in 
implementations  tliat  were  incompatible  in  many  details,  alUiough  system  models  and  basic  concepts  were 
fairly  consistent  across  most  implementations. 

Although  the  Corf:  system  was  proposed  in  1977,  and  was  revised  in  1979.  in  five  years  it  has  not  yet 
become  an  official  standard,  and  may  never  baomc  one,  due  to  the  success  of  Furopcan  standardization 
cfroi  ls.  There  has  been  much  more  experience  in  the  areas  of  portability  and  device  independence  since  the 
1979  report,  as  well  as  some  rccoiisidcration  of  the  way  modeling  and  viewing  were  separated  in  C0RF:(133J. 
Since  these  issues  arc  also  important  in  a  distributed  system,  the  Corf:  system  was  not  suitable  for  our  work. 
However,  Corf  influenced  subsequent  standardization  attempts,  described  in  the  next  sections,  tliat  have 
overcome  some  of  its  problems. 
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2.1 .2  The  Graphical  Kernel  System 

The  Graphical  Kernel  Sysicm  [64]  has  become  a  popular  standard  that  started  in  Europe  with  the  German 
DIN  (llcutchcs  Institute  fuer  Normung)  and  spread  to  America.  German  standards  are  specified  and 
adopted  more  quickly  than  American  standards  because  DIN  is  a  government  body  while  ANSI  is  a  volunteer 
organization  requiring  the  consensus  of  competing  industrial  representatives.  Although  they  are  intended  to 
be  as  close  as  possible,  there  are  some  slight  differences  between  the  ISO  GKS  and  American  National 
Standards  Institute  Committee  on  Computer  Graphics  Programming  languages  (ANSI  X3H3)  version  of 
GKS.  Most  notably,  due  to  tlie  complexity  of  the  GKS  standard  (which  already  has  nine  levels  of  subsets) 
ANSI  commitlco  X3H35  has  defined  a  subset  of  the  lowest  level  of  functionality,  called  the  Programmer’s 
Minimal  Interface  to  Graphics,  or  PMIG  [122, 2]. 

2.1 .2.1  GKS  Workstations 

GKS  uses  the  workslaiion  concept  to  represent  some  logical  input  devices  and  one  associated  output  device. 
Ihis  is  in  contrast  to  CORE  in  which  only  supports  one  view  surface  and  does  nut  support  any  relationship 
between  input  events  from  different  input  devices.  GKS  explicitly  states  that  one  application  can  manipulate 
multiple  workstations;  no  mention  is  made  of  several  applications  sharing  a  single  workstation.  ITie  idea  of 
placing  the  I/O  devices  on  a  physically  separate  machine  from  tlie  one  running  the  application  program  was 
one  of  tlic  original  motivations  for  the  workstation  concept  [48],  but  most  implementations  of  GKS  have  run 
on  only  one  machine.  Section  2.1.2.7  will  discuss  the  problems  involved  in  a  distributed  GKS 
implementation,  llie  distribution  capability  has  some  subtle  but  important  effects  on  the  structure  of  GKS. 

2.1 .2.2  GKS  Output  Primitives 

'fhe  graphics  primitives  used  in  GKS.  similar  to  those  in  CORii,  are  the  following  six: 

1.  Polyline;  A  set  of  connected  lines  drawn  between  a  list  of  points. 

2.  Polymarker:  Symbols  of  one  type  arc  centered  at  given  positions. 

3.  Text:  Character  strings  arc  drawn  at  a  given  position.  TTicrc  arc  many  attributes  to  control  the 
orientation,  spacing,  and  justincatiun  of  text. 

4.  Fill  Area:  A  polygon  which  may  be  filled  with  a  uniform  color,  pattern,  or  hatch  style. 

5.  Pixel  Array:  An  array  of  pixels  with  individually  specified  colors  or  intensities  is  displayed. 

6.  Generalized  Drawing  i'riniitive:  A  set  of  points  is  liansfonncd  and  passed  through  to  the  device 
dependent  driver. 

'Ilic  generalized  drawing  primitive  is  intended  to  lake  advantage  of  special  functions  of  tlic  workstation,  such 
as  the  ability  to  draw  arcs  or  curves.  Note  that  there  is  no  notion  of  current  position  as  in  CORI-,  and 
operations  are  in  tw«i  dimensions  only.  Three  dimcnsitrnal  extensions  arc  currently  under  development. 

2. 1.2.3  GKS  Attributes 

Abstracting  slightly  from  the  hard-copy  analogy.  GKS  and  CORi:  retain  current  values  for  each  of  several 
aiiribulcs,  representing  the  suite  of  tlic  drawing  device  used  for  relevant  output  primitives.  Thus,  although  the 
notion  of  current  position  dws  not  appear  in  GKS.  the  suite  variables  necessary  to  simulate  a  drawing  device 
arc  still  needed.  For  example,  the  polyline  primitive  has  line-type  (solid,  dashed,  etc.),  width,  and  color 
attributes.  However,  in  GKS  bundle  tables  can  be  used  to  group  attributes.  Instead  of  specifying  every 
attribute  on  every  output  primitive,  an  index  into  the  bundle  UibIc  (a  small  integer)  is  specified,  and  the  Uiblc 
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gives  values  for  all  the  attributes.  For  example,  instead  of  specifying  a  color  absolutely  everywhere  it  is  used, 
it  could  be  defined  only  once  to  simplify  changes. 

2.1 .2.4  GKS  Segments 

GKS  segments  are  named  with  integers  specified  by  the  application.  Segments  may  be  transformed,  made 
visible  or  invisible,  highlighted,  ordered  from  front  to  back,  deleted,  renamed,  and  inserted  into  other  open 
segments.  Kvery  primitive  within  a  segment  can  have  an  attribute  called  the  pick  identifier  vihkh  csUiblishes  a 
second  level  of  naming  for  use  with  the  pick  input  device.  However,  the  primitives  within  a  segment  cannot 
be  modified;  the  pick  identifier  serves  only  to  distinguish  parts  of  a  picture  used  for  graphical  input  'Ihere  is 
an  explicit  fimetion  to  set  tlic  pick  identifier.  All  primitives  added  to  the  segment  until  the  next  call  to  this 
function  will  have  tlic  same  pick  identifier. 

In  GKS  segments  can  be  posted  on  actual  workstations,  called  Workstation  Dependent  Segment  Storage  or 
Wdss.  In  addition  segments  can  be  sent  to  Workstation  Independent  Segment  Storage  (Wiss).  Segments  can 
be  moved  back  and  forth  between  Wiss  and  Wl>ss  (actual  workstations)  under  control  of  the  application 
program. 

2. 1.2. 5  Graphical  Input  in  GKS 

The  concept  of  logical  input  devices  was  used  as  a  basis  for  extending  device  independence  to  graphical 
input  in  GKS  as  well  as  CORI- (152].  The  Coul-  system  treated  input  and  output  functions  as  orthogonal 
concepts,  so,  for  example,  the  selection  of  view  surfaces  had  no  effect  on  echoing.  On  the  other  hand,  GKS 
ass(x:iatcs  logical  input  devices  with  workstations.  GKS  provides  tlie  following  classes  of  input  devices: 

Locator  Provides  a  position  in  world  coordinates  and  a  transformation  number,  determined  by  the 
viewport  in  which  the  input  occurred.  A  trackball  or  joystick  is  the  typical  locator  device. 

Stroke  Provides  a  series  of  positions  in  world  coordinates  and  a  transfonnation  number. 

Valuator  Provides  a  single  real  number  scalar  value,  from  a  onc-dimcnsional  device  such  as  a  rotary 
dial. 

Choice  Provides  tlic  ability  to  ch(K)sc  among  alternatives,  like  the  button  device  in  CORE.  A  non- 
negative  integer  indicates  a  selection,  and  zero  indicates  no  selection. 

Pick  Provides  a  pick  status,  a  segment  name  and  a  pick  identifier  (the  item  “picked”).  Primitives 
outside  segments  cannot  be  picked,  riic  typical  pick  device  is  the  light  pen,  which  senses 
when  tlic  beam  of  a  CR  T  pas.scs  over  tlic  point  underneath  its  tip. 

String  Provides  a  character  string,  similar  to  tlic  keyboard  device  in  CORIi. 

Ilie  original  GKS  specification  did  not  have  the  stroke  device  clas.s.  since  it  can  easily  be  built  on  top  of  other 
primitives,  given  a  suitable  semantic  model  of  input  devices  (1 13|. 

At  any  lime  a  logical  input  device  is  in  one  of  three  modes: 

Request  Allows  tlic  input  device  to  accept  request  commands.  When  the  application  issues  a  requesL  GKS 
waits  until  input  is  entered,  or  the  operator  enters  a  break  action.  Control  is  then  passed  back  to 
the  application. 

Kvent  GKS  maintains  an  event  queue.  An  event  report  on  this  queue  contains  the  logical  device 
number  and  a  value  from  tliat  device.  F’vcnts  arc  generated  asynchronously  by  operator  action. 
An  application  can  wait  for  an  evenL  remove  it  from  tlic  queue,  or  flush  events  from  the  queue 
without  reading  them. 


18 


PARimONlNG  OI-  ITJNCnON  IN  A  DISTRIBUTIiD  GRAPHICS  SYSTCM 


Sample  Allows  the  input  device  to  accept  sample  commands.  Sampled  devices  do  not  cause  events  on  any 
queue,  but  arc  instead  polled  by  the  application.  When  the  application  issues  a  sample  command, 
GKS  returns  the  current  value  of  the  device  without  waiting. 

2.1 .2.6  GKS  as  a  Standard 

Like  Corf,.  GKS  was  defined  as  an  abstract  set  of  operations  instead  of  a  particular  interface  in  a  particular 
programming  language.  However,  efforts  are  underway  to  standardize  language  bindings,  so  there  is  a  greater 
chance  that  GKS  programs  can  truly  be  portable.  A  Fortran  binding  is  included  in  the  ANSI  standard,  and 
work  on  other  language  bindings  such  as  C  [114)  is  underway.  Unfortunately,  even  these  standard  binding 
efforts  arc  hampered  by  the  many  different  dialects  of  these  languages. 

Full  GKS  (highest  levels  for  both  input  and  output)  includes  110  functions  plus  7S  inquiry  functions.  The 
lowest  level  of  ISO  GKS  requires  52  functions  plus  38  inquiry  functions.  The  lowest  level  of  ANSI  GKS  (no 
input)  requires  31  functions  plus  17  inquiry  functions  [122].  Of  course,  counting  the  number  of  functions  is  a 
very  coarse  measure  of  complexity,  but  by  most  measures  GKS  seems  to  be  a  much  simpler  system  to 
implement  tlian  CORIL  There  arc  proposals  for  3D  extensions  to  GKS,  since  this  lack  is  the  major  reason  why 
American  groups  like  SiGGRAPll  oppose  the  standard. 

2.1 .2.7  A  Distributed  Implementation  of  GKS 

One  of  the  principle  advantages  of  GKS  for  distributed  workstation-based  systems  is  the  ability  of  the 
workstation  concept  to  allow  potential  distribution.  A  recently-announced  product  called  nova*GKS  is  an 
implementation  of  GKS  that  can  be  distributed  acrc^  several  machines,  but  still  allows  only  one  application 
to  be  run  at  a  time,  and  handles  only  one  host  at  a  time  [149).  Nevertheless,  nova*gks  can  be  examined  as  an 
example  of  a  distributed  graphics  system  using  GKS.  The  nova*gks  implementation  consists  of  four  major 
layers: 

1.  GKS  Interface  ■  provides  the  functions  specified  in  the  GKS  standard,  implemented  as  modules 
that  arc  linked  with  an  application  program. 

2.  Workstation  Manager  -  handles  device  independent  aspects  of  workstations,  including 
workstation  independent  segment  storage  (WiSS). 

3.  Workstation  Supervisor  -  provides  software  simulation  of  GKS  functions  that  arc  not  directly 
supported  by  tlic  physical  workstation  or  the  device  driver, 

4.  Device  Driver  -  low  level  device  driver,  which  implements  the  graphics  primitives  and  maps  into 
device  coordinates. 

ilctween  each  set  of  layers,  an  interesting  coupling  scheme  is  used.  Instead  of  directly  calling  tlic  functions  in 
the  lower  level,  all  accesses  must  funnel  down  through  a  single  lower  level  supervisor  function.  'Ihc  lower  level 
supervisor  can  then  eillicr  be  a  large  case  slalcinciU  which  fans  out  lo  all  the  appropriate  lower  level 
modules,  or  it  can  encode  Uie  runclions  (»ver  a  communication  line  lo  a  remote  pnx;css«»r.  where  die  fan-out 
then  takes  place.  Ihus  the  choice  of  where  the  communication  hikes  pltKc  and  even  Uie  kind  of  protocol  used 
can  be  done  at  link-time  wiUi  no  changes  to  Uie  rest  of  Uie  package. 

2.1 .2.8  Adding  Structure  to  GKS 

Proposed  GKS  output  level  3  supports  structured  segments  [130).  'Ihc  later  Chapters  of  Uiis  Uicsis  provide 
evidence  Uiat  structured  segments  provide  perfonnance  increases  in  a  dislrihuled  environment.  As  Uie  name 
implies,  this  proposal  is  upward-compatible  with  die  other  levels  of  GKS.  'Ihc  main  addition  is  Uie  ability  of 
segments  to  call  other  segments.  An  existing  segment  can  be  reopened  fur  editing,  and  elements  can  be 
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inserted  and  deleted.  Hditing  is  performed  using  an  element  number,  an  integer  count  of  elements  within  a 
segment.  For  example,  the  first  clement  in  a  segment  is  number  1,  then  2,  etc.  It  is  not  clear  what  happens 
when  an  clement  is  added  or  deleted  from  the  middle  of  a  segment  -  probably  all  the  elements  change  their 
numbers,  leading  to  possible  confusion.  For  this  reason  labels  may  be  used  to  refer  symbolically  to  elements 
instead  of  using  their  numbers,  labels  arc  known  only  within  a  segment;  separate  external  names  arc  used  to 
name  whole  segments. 

'ITic  transformation  of  each  primitive  is  the  concatenation  of  all  segment  transformations  of  the  ancestors  of 
the  primitive.  Thus  a  stack  of  matrices  is  stored,  starting  with  the  identity  transformation,  multiplying  the 
current  matrix  by  the  call  transformation  matrix  and  the  called  segment  transfoimation  matrix,  and  pushing 
tlic  result  onto  the  stack  for  each  segment,  starting  with  root  segments. 

Ihc  contents  of  segments  can  retrieved,  and  segments  can  be  stored  on  mcuifilcs.  'llicrc  is  a  call  to  write 
private  data  to  the  segment,  which  seems  to  indicate  a  desire  to  u.sc  the  segment  facility  as  an  application 
database.  A  total  of  15  new  functions  arc  added  to  GKS  for  tliis  level,  so  the  complexity  of  GKS  is  increased 
only  slightly.  However,  run-time  overhead  could  be  significant,  since  a  total  of  29  attributes  (in  addition  to 
the  transformation  matrix)  arc  pushed  and  popped  during  each  segment  Iravcr&il.  'ITic  GKS  output  level  3 
proposal  was  a  reaction  to  the  PlliGS  effort  to  be  described  next.  The  principle  advantage  is  compatibility 
with  many  GKS  implementations  and  applications  currently  being  built 


2.1.3  The  Programmer’s  Hierarchical  Interactive  Graphics  Standard 

A  more  recent  standardization  effort  has  produced  the  Programmer’s  Hierarchical  Interactive  Graphics 
Standard  (PillGS)(4].  As  its  name  implies,  PlliGS  allows  arbitrarily  deep  hierarchical  specification  of 
graphical  objects,  instead  of  the  less  general  segmentation  mechanism  in  Core  and  current  GKS.  One  of  the 
stated  reasons  for  this  more  elaborate  structure  of  objects  is  the  increased  effectiveness  of  making  changes  to 
the  display  in  support  of  interactive  graphics.  An  important  design  criterion  was  to  provide  adequate 
performance  in  interactive  applications,  by  taking  advantage  of  today’s  more  powerful  graphics  workstations. 

The  actual  display  primitives  in  PlliGS  arc  similar  to  those  of  GKS,  altlrough  tlrcy  a|)pcar  in  a  more 
elaborate  framework,  fhcrc  are  both  2-dimcnsional  and  3-diincnsional  functions.  Display  primitives,  along 
with  attributes,  viewing  operators,  modeling  transformations,  and  references  to  other  stnicturcs,  can  all  be 
elements  of  a  structure.  Structures  can  be  edited,  by  deleting  and  inserting  elements. 

PlliGS  includes  the  concept  of  workstations,  but  workstations  do  not  logically  store  the  graphics  data.  An 
application  program  defines  a  picture  by  adding  entries  to  tlic  device  independent  structure  database.  The 
workstation  driver  tlicn  reads  tlic  database  to  cause  tire  physical  terminal  screens  to  be  drawn.  F.ach 
workstition  has  at  most  one  fixed-size  rectangular  viewing  surface,  and  may  have  any  number  of  input 
devices.  Workstitions  have  descriptor  tables  that  describe  the  capabilities  of  tire  workstation.  'I'hc 
applications  program  can  iiiquirc  about  which  capabilities  are  available  and  adapt  accordingly.  Although 
programs  written  using  tliis  feature  can  work  on  several  different  types  of  workstitions,  the  application 
programmer  must  anticipate  all  possible  configurations  when  the  program  is  written. 

Filch  attribute  corrc.sponds  to  a  “register”  of  a  virtual  workstition;  these  registers  are  changed  by  commands 
in  the  header  of  eiich  structure,  and  objects  arc  rendered  in  llie  color  that  is  in  the  rcgistcre  .it  the  time  of  the 
rendering.  Unfortunately  tliis  introduces  much  complexity  in  tlie  device  driver,  because  it  must  keep  track  of 
tlic  state  of  all  of  tlicsc  virtual  registers. 
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2.1 .4  The  LBL  Network  Graphics  System 

The  Network  Graphics  System  was  developed  by  [.awrence  Berkeley  Laboratories  as  an  extension  of  CORE 
for  a  network  environment  [24].  Although  this  is  an  on-going  development  effort,  as  opposed  to  a  proposed 
standard,  NGS  is  similar  in  spirit  to  PliiGS,  Ukc  GK.S  and  Core,  it  was  designed  for  vector  refresh  and 
storage  tube  devices,  and  later  extended  to  raster  devices. 

The  Network  Graphics  System  allows  the  definition  of  hierarchical  structures,  which  can  be  deleted  or 
appended,  but  nut  otherwise  modified  [25],  Attribute  information  is  stored  separately  from  the  object 
definitions,  so  it  can  be  changed  dynamically.  Attributes  can  be  bundled,  or  controlled  explicitly  and 
individually,  liven  though  bundling  capability  is  provided,  the  authors  state  that  direct  control  is  expected  to 
be  used  most  oBcn. 


2.1 .5  Virtual  Device  Interface  and  Metafile 

Since  most  graphics  packages  use  some  form  of  normalized  device  coordinates,  this  is  another  logical 
candidate  for  a  standard  partitioning  point,  'flic  graphics  package  can  be  written  in  terms  of  a  virtual  device, 
which  is  then  implemented  on  the  physical  device.  Ihe  Virtual  Device  Interface  specification  (VDl)  is  yet 
another  graphics  standardization  effort  of  ANSI  committee  X3H33  [7],  As  shown  in  figure  2-2,  the  Virtual 
Device  Interface  specifies  tlie  low  level  target  for  graphics  packages.  'ITte  Virtual  Device  Metafile  (VDM) 
standard  [5],  similar  to  that  developed  at  lx)S  Alamos  National  Laboratory  [110],  is  an  encoding  of  the  Virtual 
Device  Interface  into  a  stream  of  bytes  to  be  stored  on  a  file. 

As  indicated  in  Figure  2-2,  tlic  VDl  specification  could  be  realized  in  a  real  device,  or  at  least  a  “black  box” 
which  the  user  treats  as  a  hardware  device.  'Phe  device  drivers  would  be  written  by  the  manufacturer  of  the 
graphics  device,  instead  of  die  author  of  the  graphics  system.  Since  the  VDl  specification  is  precisely  defined, 
it  should  be  possible  to  put  die  implemcnwtion  of  the  the  virtual  device  on  a  different  machine  than  the  one 
running  the  graphics  package.  Unfortunately,  this  interface  involves  bodi  a  high  frequency  and  large  amount 
of  infomiation  interchange.  'Ihus  it  may  nut  be  suitable  for  partitioning  when  communication  costs  arc  high. 


2.1 .6  Videotex  and  Teletext  Systems 

Other  systems  have  been  developed  for  situations  with  high  communication  costs  between  die  graphics 
system  and  die  device.  F,xamplcs  diat  deal  with  partitioning  arc  Videotex  and  Teletext.  Videotex  is  an 
interactive  communications  service  that  delivers  color  graphics  infonnation  from  centralized  databases.  This 
infonnation  is  most  often  delivered  over  telephone  lines,  decoded  by  a  dedicated  hardware  device,  and 
displayed  on  a  television  monitor.  Thus,  videotex  is  intended  for  direct  use  by  consumers,  combining  two  of 
the  most  familiar  pieces  of  electronic  equipment  in  most  homes  today:  die  telephone  and  die  television  set. 
In  addition  to  providing  informalioii.  videotex  allows  users  to  perform  transaction  such  as  ordering  products. 
One  of  the  major  standards  in  diis  area  is  the  North  American  Prcscntilion  Level  ProtiKol  Syntax 
(NAl’l  I’Sjjfi].  Since  iclephone  companies  in  llurope  arc  generally  smaller  and  run  by  die  government  dicrc 
have  already  been  several  videotex  systems  in  operation  in  Britain  (Fl<l5l  i;i,)and  l•'rancc  (AN  i  riOl'lO. 

Teletext  is  a  similar  technique  designed  to  bring  information  service  to  home  consumers.  I  lowcver,  teletext 
uses  one-way  broadcast  transmission,  often  dirough  cable  television  systems.  The  major  standard  in  diis  area 
is  the  North  American  Broadcast  rcictext  Specification  (1 1].  'Ihis  standard  specifics  exactly  how  die  messages 
arc  encoded  for  transmission,  which  arc  die  lower  levels  (physical  to  transport)  of  protocols,  riic  data  can  be 
transmitted  on  standard  television  channels,  during  the  vertical  blanking  interval,  or  entire  channels  can  be 
dedicated  to  teletext.  Ilic  presentation  level  of  NAltl'S  is  NARLPS. 

Unfortunately,  since  these  protocols  arc  directed  to  a  consumer  market,  they  arc  limited  in  dicir  abilidcs. 
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For  example,  they  arc  often  tied  to  specific  common  video  resolutions  that  are  lower  than  typical  scientific 
workstations.  More  importantly,  they  are  intended  for  very  inexpensive  terminals,  so  they  would  waste  tlie 
power  of  most  modern  workstations.  In  particular,  they  handle  only  one  activity  at  a  time.  Since  we  are 
interested  in  future  computing  systems  that  contain  multiple  processors  executing  concurrently,  we  will  next 
examine  systems  that  can  manage  this  concurrency. 

2.2  Object-Oriented  Window  Systems 

The  desire  to  use  graphics  as  an  aid  to  user  interface  has  led  to  the  development  of  object-oriented  window 
systems.  In  these  systems,  there  might  not  be  application  programs,  per  se,  but  rather  objects  tliat  respond  to 
the  control  of  the  user.  An  interesting  paraphrase  (►f  the  object-oriented  window  system  philosophy  is  “don’t 
call  us.  we’ll  call  you”,  'lhat  is,  instead  of  the  application  program  calling  fiinctions  in  the  graphics  package, 
the  graphics  system  calls  user-defined  functions  to  display  themselves  when  needed.  This  mechanism,  the 
graphics  system  calling  client  software,  is  referred  to  as  an  up-call,  in  contrast  to  down-calls  of  traditional 
graphics  packages. 

This  difference  in  control  reflects  the  different  application  areas  for  which  these  systems  were  developed. 
ITie  graphics  systems  discussed  in  the  previous  section  consider  the  picture  to  be  the  main  purpose  of  the 
program.  Ihus  they  are  suitable  for  application  areas  such  as  commercial  animation  in  which  realism  and 
precise  control  of  the  picture  arc  most  important.  However,  many  programs  arc  intended  to  perform  some 
other  function,  with  graphics  as  a  side-effect.  For  example,  the  principle  function  of  an  integrated  circuit 
editor  is  to  edit  integrated  circuits,  nut  to  draw  beautiful  pictures  of  them.  In  fact,  the  information  being 
displayed  by  programs  is  often  abstract,  so  “realism”  is  meaningless  in  these  cases. 

2.2.1  Smalltalk 

Smalltalk  is  a  scries  of  languages  based  heavily  on  graphics  with  an  object-oriented  window  system  [58]. 
The  language  was  first  designed  as  a  tool  for  research  by  the  I. earning  Research  Group  at  Xerox  Palo  Alto 
Research  Center.  In  tlieir  view,  the  ideal  system  would  use  powerful  yet  compact  and  portable  “personal 
dynamic  media"  which  students  could  use  and  interact  with  [90].  I  he  ideal  pcreonal  dynamic  media  was 
called  the  dynabook,  and  corresponds  to  a  futuristic  view  of  today’s  graphics  workstations. 

A  Smalltalk  system  is  composed  of  objects,  which  consist  of  some  private  memory  and  a  set  of  operations. 
Ilic  programmer  specifics  lliesc  operations  as  metimis  that  arc  invoked  when  objects  receive  messages. 
Advantiges  of  such  an  approach  include  extensibility;  applications  can  define  their  own  graphics  objects  and 
primitives  because  screen  updating  is  controlled  by  Uk  application  itself.  On  the  other  hand,  the  programmer 
can  declare  a  class  to  be  a  subclass  of  another  clas.s,  so  dial  operations  are  inherited.  Only  the  new  operations 
have  to  be  denned,  so  the  extensibility  can  be  performed  without  much  programming  overhead. 

2. 2. 1.1  The  Smalltalk  Environment 

Smalltalk  is  a  graphical,  interactive  programming  environment  One  key  aspect  of  tlie  user  interface  of 
Sinalluilk  is  the  use  of  a  pointing  device  such  as  a  mouse  to  select  items  instead  of  typing  commands  [SO], 
Many  of  these  ideas  originated  in  the  NFS  system  at  Suinford  Research  Institute  by  F'nglebart  and  others 
during  die  late  19f)0s  and  early  1970s  [49|.  Although  NFS  was  u.scd  only  within  SRI,  the  system  is  now  called 
Augment  and  marketed  by  l  ymcshare  corporation. 

Smalltalk,  unlike  Augment  is  intended  to  be  implemented  tm  self-contained  personal  computers  which 
include  a  single  large  address  space  and  a  disk,  llnfortunately,  implementations  ofSmalltilk  on  commercial 
microcomputers  have  failed  due  to  die  perfoimancc  problems  of  small  processors  and  storage  devices.  One  of 


22 


PARTITIONING  OT  f  UNCTION  IN  A  DISTRIBUTED  GRAPHICS  SYSTEM 


the  few  machines  that  can  run  Smalltalk  with  adequate  performance  is  the  Dorado,  a  very  high-performance 
and  expensive  scientific  computer  developed  at  Xerox  PARC  [75).  Workstations  arc  becoming  more 
powerful,  but  machines  in  the  class  of  the  Dorado  will  be  expensive  for  some  time  to  come.  Although  using 
the  object-oriented  approach  of  Smalltalk  at  all  levels  may  not  be  desired,  the  user  interface  advances  arc 
being  adapted  to  other  systems. 

2.2.1 .2  Smalltalk  User  Interface 

The  user  interface  of  a  Smalltalk  system  typically  consists  of  several  Views  of  objects  on  a  gray  background. 
The  name  “window  system”  comes  from  the  appearance  tliat  these  views  arc  “windows”  into  tlic  world  of 
objects.  ’ITic  user  controls  a  small  arrow  called  a  cursor  by  moving  the  pointing  device.  Directing  activity  to  a 
particular  piece  of  information  in  a  view  is  done  by  making  a  seleclion.  Hie  system  provides  immediate  visual 
feedback  to  indicate  the  selection.  For  example,  the  selection  is  often  displayed  complemented  (black  to 
white  and  white  to  black).  At  any  particular  time,  only  one  view  is  selected,  indicated  by  a  conplcmcntcd 
title,  and  appearing  to  lie  on  top  of  any  other  overlapping  views. 

Pop-up  Menus  arc  also  used  to  select  commands.  In  response  to  a  user  action  such  as  a  button  press,  a  list  of 
commands  appears  underneath  the  cursor.  While  the  button  is  held  down,  the  cursor  is  moved  to  select  one 
of  the  commands  in  the  menu.  When  the  button  is  released,  the  selected  command  is  ciirricd  out.  Some 
command  menus  arc  particular  to  die  object  being  displayed  in  the  selected  view,  while  other  command 
menus  are  uniform  across  the  endre  system.  Similar  powerful  user  interfaces  have  been  incorporated  into 
other  object-oriented  single  language  integrated  environments,  such  as  on  die  New  Window  System  for  the 
Symbolics  l.isp  Machine,  through  a  language  extension  called  Flavors  diat  provides  objects  with  inheritance 
of  operations  from  muldpic  super-classes  [157]. 


2.2.2  “Lisa  Technology” 

The  Star  word  processing  system  by  Xerox  corporation  [124]  incorporated  many  of  these  object-oriented 
ideas  into  a  commercial  product  using  die  fairly  conventional  programming  language  Mesit  [87].  'Hie  Star 
system  used  an  analogy  between  the  graphics  screen  and  a  convcntioniil  desk  top.  Hie  screen  contained  icons, 
small  symbolic  images  that  invoked  actions  when  selected  by  the  mouse.  For  example,  moving  a  dcxrument  to 
a  filing  cabinet  icon  caused  it  to  be  stored  in  a  file  server,  while  moving  it  to  a  printer  icon  caused  it  to  be 
printed.  The  Star  developers  claimed  that  interfaces  using  icons  were  easier  to  learn  and  less  error-prone  than 
conventional  textual  command  languages. 

The  Cedar  Viewers  System  [92]  was  developed  at  the  Xerox  Computer  Science  l.aboratory  for  their 
prototype  software  development  environment  called  Cedar  [46. 140].  The  Cedar  environment  was  intended 
to  combine  the  best  feiitures  of  Inter!  isp.  in  particular  the  Programmer’s  Assistant  [139],  with  the  Mesa 
program  development  environment  [99].  The  application  program  specified  prixrcdures  to  be  called  in 
response  to  input  events.  Iliese  pnxrcdurcs  used  tlic  Cedar  Graphics  Package  to  draw  tlic  objects  they 
represent  on  the  screen  when  requested  [154]. 

Unfortunately  the  Star  system  surTcred  from  slow  response  times,  and  tlic  Cedar  system  required  very 
expensive  computers  such  as  the  IXirado  to  run  encclivcly.  Similar  user  interface  functionality  was  made 
available  for  much  lower  cost  with  the  introduction  of  the  Apple  Lisa  and  Miicintosh  computer  systems  [159]. 
Hie  Lisa  and  Macintosh  software  borrowed  the  desk  top  metaphor  from  Star,  with  icons  representing  data 
objects  such  as  documents.  Since  these  machines  were  tlic  first  to  gain  widespread  attention,  such  systems 
have  been  called  examples  of  “Lisa  Technology”.  Lisa  was  intended  as  a  low-cost  olTicc  personal  computer, 
so  its  performance  was  also  fairly  slow,  with  some  operations  taking  30  seconds.  This  was  due.  for  example,  to 
swapping  of  several  megabytes  of  object  code  into  a  physical  memory  that  was  only  expandable  to  one 
megabyte. 
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2.2.3  Other  Window  Systems 

An  important  research  effort  has  been  the  Canvas  system  [13],  and  its  successor,  called  Sapphire,  developed 
at  Carnegic-Mellon  University  for  the  Spice  project.  Sapphire  (Screen  Allocation  Package  Providing  Helpful 
Icons  and  RccUingular  Environments)  provides  a  virtual  bitmap  which  applications  can  manipulate  any  way 
they  wish  [95],  Applications  can  specify  exact  kKation  and  shape  of  the  windows,  or  be  notified  when  location 
and  shape  is  changed.  Each  window  can  be  transparenL  or  can  take  responsibility  for  remembering  what  it 
obscures.  Kor  example,  pop-up  menus  are  implemented  as  windows. 

Some  of  the  user  interface  ideas  of  object-oriented  window  systems  have  been  implemented  on  traditional 
text-only  [158,65]  or  vector  display  tcnninals[89|,  although  a  lull  bitmap  display  is  desirable,  and  becoming 
more  prevalent,  especially  in  research  environments  [23],  More  important  is  the  requirement  of  shared 
memory  for  the  many  procedure  calls  in  this  approach.  Some  systems  have  extended  tlie  up-call  concept  with 
remote  pnKedure  calls,  with  inconclusive  performance  results  [59]. 

2.3  Virtual  Terminal  Management  Systems 

As  we  have  seen  in  the  last  two  Sections,  graphics  packages  put  the  application  in  control,  while  object- 
oriented  window  systems  put  die  user  in  control.  This  distinction  between  main-stream  standardization 
efforts  and  die  window  system  line  of  development  has  only  been  touched  upon  in  the  literature.  Partly  this  is 
because  of  the  delay  involved  in  standardization  efforts;  the  current  standards  were  designed  for  hardware  of 
more  than  ten  years  ago.  Since  the  workstation-based  distributed  systems  described  in  Chapter  1  did  not  exist 
ten  years  ago.  these  standards  do  not  easily  lend  themselves  to  a  distributed  environment  [9]. 

One  of  the  few  efforts  to  combine  these  two  lines  of  development  was  a  window  system  for  a  storage  tube 
display  [115].  The  basic  observation  from  this  work  was  dial  tlic  advantages  of  the  two  approaches  can  be 
combineil  if  die  problem  is  viewed  as  one  of  resource  management.  Since  a  major  role  of  an  operating  system 
is  to  manage  hardware  resources,  recent  research  in  resource  management  by  operating  systems,  in  particular 
the  management  of  terminal  systems,  should  be  examined. 

2.3.1  Network  Virtual  Terminals 

'I  he  name  "virtual  terminal"  was  first  used  during  the  development  of  protocols  for  long-haul  networks 
[43].  Problems  arose  due  to  die  large  number  of  different  operating  systems  and  terminals  that  needed  to 
communicate  in  the  network.  If  diere  were  n  types  of  terminals  and  in  types  of  operating  systems,  dien  n  x  m 
terminal  handlers  were  needed.  This  led  to  very  large  software  costs  as  networks  diversified. 

Instead  of  forcing  each  computer  system  to  handle  all  possible  types  of  terminals,  each  could  handle  only 
one  absiractly-defined  network  virtual  terminal.  The  conversion  from  virtual  to  real  terminal  would  be 
performed  by  the  machine  to  which  the  terminal  directly  connects.  This  is  similar  to  the  virtual  device 
approach  described  in  the  previous  section,  also  used  to  provide  device  independence.  As  workstations 
become  more  powerful,  they  can  be  considered  as  nodes  in  a  network,  and  the  virtual  to  physical  terminal 
translation  could  be  perfonned  by  workstations. 

2.3.2  Rochester’s  Intelligent  Gateway  VTMS 

Another  advantage  of  the  virtual  terminal  concept  is  the  support  of  multiple  applications  simultaneously. 
Traditional  graphics  packages  described  in  die  first  section  of  diis  chapter  assume  one  application  is  in  total 
control  at  any  time.  Although  the  window  systems  discus.scd  in  die  previous  scxlion  display  nuilliple  contexts, 
usually  only  one  application  is  active  at  any  time  on  the  personal  computer.  One  of  the  first  attempts  to  use 
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multiple  concurrent  processes  in  multiple  windows  for  program  development  was  a  system  called 
Copilot  [136].  'fhe  ability  to  monitor  concurrency  naturally  through  a  window  system  has  been  determined 
by  the  author  to  be  invaluable  in  a  distributed  environmenL 

Rochester’s  Intelligent  Gateway  was  designed  to  provide  a  uniform  user  interface  to  manage  distributed 
resources  [78, 79],  The  Rig  Virtual  Terminal  Management  System  (VTMS).  was  one  of  tlie  earliest  systems  to 
provide  simultaneous  access  to  multiple,  possibly  distributed  applications  [77].  Vl'MS  mapped  any  number 
of  virtual  terminals  to  a  physical  screen  simultaneously,  and  each  virtual  terminal  could  be  written  to  or 
queried  for  input  by  applications  throughout  the  distributed  system. 

In  RIG  the  resource  management  problem  was  viewed  fundamentally  as  a  problem  of  process 
management,  with  requests  sent  to  server  prwesscs  through  messages.  I'able-driven  command  interpreters 
were  also  provided  to  enforce  a  consistent  user  interface  across  different  tools.  These  contributions 
significantly  influenced  many  subsequent  efforts,  incluvling  the  research  described  in  this  thesis.  However, 
VI  MS  did  not  provide  graphics  support,  nor  did  it  provide  effective  terminal  emulation. 


2.3.3  Apollo  Domain 

The  Apollo  Domain  workstation-based  distributed  system  uses  some  of  the  concepts  of  virtual  terminals  as 
developed  in  VTMS  [8].  Domain  also  provides  a  distributed  file  system,  and  other  distributed  objects. 
However,  its  architecture  applies  to  only  one  particular  manufacturer  since  tlie  network  transparency  is 
handled  at  a  very  low  level:  demand  paged  virtual  memory.  Since  most  research  computing  environment  are 
very  heterogeneous.  Domain  cannot  be  used  to  solve  all  partitioning  problems  [37]. 


2.3.4  The  Virtual  Graphics  Terminal  Service 

The  extension  of  the  virtual  terminal  concept  to  graphics  is  the  subject  of  the  next  two  chapters.  The  system 
described  here  is  called  the  Virtual  Graphics  Terminal  Service,  or  VGTS^  the  name  reflecting  the  VTMS 
conceptual  base  [81].  The  VG'I’S  takes  an  approach  different  from  l^nnain's,  handling  transparency  at  a 
much  higher  level:  abstract  operations.  Ihis  allows  operations  to  be  partitioned  between  machines  of  very 
different  amhitcctures  running  different  operating  systems,  and  using  vastly  different  network  technology. 

'The  VG  TS  interface  to  the  programmer  is  much  simpler  tlian  most  of  tlie  systems  discus.scd  in  this  chapter. 
For  example,  the  NGS  working  design  doeument|2S]  has  a  partial  list  of  181  functions,  while  tlie  VG'l'S 
programmer's  interface  is  about  30  functions.  Of  course  these  other  systems  may  provide  more  functionality 
in  some  areas,  but  it  is  not  clear  tliat  this  functionality  is  always  necessary. 

The  next  two  chapters  will  provide  more  details  on  the  architecture  and  implementation  of  the  VGTS, 
including  more  comparisons  to  both  standards  and  window  systems.  Chapter  5  will  examine  these  types  of 
design  tradc-olfs  in  depth. 


lounccd  "Vcc  Gcc  Tcc  F&s".  that  is.  there  is  no  attempt  at  pronunciation  of  the  acronym. 


ARCl  UTCCrURE  OF  Tl  IE  VGTS 
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—  3  — 

Architecture  of  the  VGTS 

As  wc  have  seen  in  tlic  last  two  chapters,  the  functional  partitioning  problem  is  an  important  one  that  is  not 
adequately  addressed  by  cither  traditional  graphics  packages  or  window  systems.  In  order  to  perform 
experiments  on  tlic  partition  of  function  wc  have  first  designed  an  architecture  for  a  distributed  graphics 
system,  as  described  in  this  chapter.  Only  the  architecture  is  described  here;  an  actual  implementation  is 
described  in  Chapter  4  and  rationale  for  the  design  is  given  in  Chapter  5. 

3.1  The  Environment 

No  single  design  will  be  appropriate  for  every  circumstance.  It  is  important  to  limit  the  scope  of  the 
anticipated  environment  because  most  systems  that  try  to  do  everything  for  everybody,  end  up  not  doing 
much  well  at  all.  lliis  section  describes  die  particular  environment  for  which  the  VGTS  was  designed. 

3.1 .1  The  Stanford  University  Network 

The  VGTS  architecture  was  designed  within  the  context  of  the  Stanford  University  Network  (SUN).  SUN  is 
a  rapidly  evolving  environment  consisting  of: 

•  graphics  workstations,  such  as  the  Xerox  1100.  Symbolics  3600.  Sun  [151  and  Iris  [391; 

•  sta  ulard  timesharing  systems,  such  as  DFCSystcm-20/TOPS-20,  Vax/Unix,  and  Vax/VMS;  and 

•  dedicated  server  machines,  for  high  quality  and  high  volume  printing,  file  storage,  terminal 
multiplexing,  and  gateway  services; 

interconnected  by  various  UKal  networks,  including  about  25  different  Hthernet  segments  [94].  Various 
machines  are  also  connected  to  long-haul  networks  such  as  the  Arpanfi  ,  cither  directly  or  through  gateways. 
This  fits  the  general  model  illustrated  in  figure  1-1. 

Sun  is  representative  of  many  workstation-lxiscd  dislribuicd  systems  currently  in  place  or  being  developed 
throughout  the  computer  research  community  [14.  1 19).  These  systems  typically  provide  die  equivalent  of: 

•  powerful  workstations  with: 

o  a  general-purpose  proccs.sor  (I  M IPS  or  more) 
o  a  large  local  physical  memory  (1  MRyte  or  more) 
o  a  liigh-rcst)lution  raster  display  (1000  by  1000  or  more  pixels) 
o  a  l.irgc  virtual  address  space  (>  20  bit) 
o  a  gr,i|rliics  input  device  (such  as  a  mouse) 
o  an  optional  disk 

e:K;h  usually  dedicated  to  a  single  user  at  a  time; 

•  a  fast  (>  1  MH/.)  communications  network  that  will  link  the  workstations; 

•  a  number  of  dedicated  prwessors  pmviding  printing,  file  storage,  general  computation  support, 
and  other  services;  and  access  to  timesharing  or  special-purpose  computers  and  to  long-haul 
computer  networks. 

The  architecture  we  are  about  to  describe  is  well-suited  to  any  such  system. 
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3.1.2  The  V-System 

The  software  environment  used  for  this  research  is  called  the  V-System.  Logically  it  consists  of  a 
distributed  kernel  and  a  distributed  set  of  server  processes.  The  distributed  kernel  consists  of  the  collection  of 
kernels  resident  on  the  participating  machines.  Communication  within  a  single  graphics  workstation  is  via 
fixed-size  synchronous  messages,  using  the  V  kernel  [31, 32].  These  message  semantics  were  originally 
developed  in  the  Thoth  [29]  system  and  latci  used  in  Verex  [30].  I'he  individual  kernels  are  integrated  via  a 
low-overhead  inter-kernel  protocol  (IKP)  that  supports  transparent  interprocess  communication  between 
machines  over  a  local  network  [164]. 

Servers  include  network  servcis,  storage  servers,  executives  (command  interpreters),  and,  of  course,  virtual 
graphics  terminal  servers.^  The  V-System  software  architecture  is  especially  tailored  to  communicate  with 
existing  timesharing  operating  systems  such  as  Unix,  VMS,  and  TOPS-20.  A  user-level  program  called  the  “V 
server”  runs  on  tlie  timesharing  machines  and  implements  tlic  V  inter-kcrncl  protocol.  Programs  running 
within  the  V  environment  can  tlien  access  file  service  or  remote  execution  of  programs  transparently  on  the 
timesharing  hosts  as  well  as  the  workstation.  Other  protocol  architectures  like  IP/TCP  [106]  and  PUP  [19]  are 
also  used  to  communicate  with  dedicated  servers  and  larger  or  more  remote  time-sharing  machines. 

The  V-System  architecture  was  designed  to  allow  flexible  interconnection,  similar  in  nature  to  hardware 
organizations.  Consider  an  operating  system  kernel  as  a  bus,  which  provides  a  standard  interface  to  connect 
modules.  In  computer  hardware,  the  bus  is  usually  a  simple,  passive  device.  The  V-System  takes  into  account 
multiple  busses  in  both  its  hardware,  as  seen  in  Figure  3-1,  and  its  software,  as  seen  in  Figure  3-2  [80].  The 
striking  similarities  between  the  hardware  and  software  organizations  arc  intentional.  Note  that  busses 
correspond  to  citlicr  operating  system  kernels  (usually  small  and  synchronous)  or  network  protocols  (larger 
and  asynchronous).  Hardware  modules  correspond  to  software  processes  in  this  analogy. 


Figure  >1:  Hardware  organi/iition  of  the  Sumford  V-System 

Hus  adapters  correspond  to  network  server  processes,  which  can  also  be  considered  protocol  converters. 
One  major  reason  for  hardware  bus  adapters  is  the  availability  of  many  peripheral  devices  for  certain  old 
busses.  Ihc  adapter  allows  the  use  of  tlic  old  peripherals  on  new  systems,  without  the  need  to  redesign  all  the 
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Wc  will  refer  lo  bo(h  ihe  service  and  the  server  as  VGTS,  The  Inter  is  the  software  module  that  provides  the  former. 
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Figure  3-2:  Software  organization  of  the  Stanford  V-System 

interfaces.  Similarly,  much  software  for  older  operating  systems  can  be  encapsulated  and  augmented  in  this 
model,  instead  of  being  replaced. 


3.1.3  The  VGTS 

In  the  V-system,  the  workstation  provides  a  virtual  terminal  service,  similar  to  tlie  VTMS  in  RIG  (78),  but 
extended  to  include  graphics.  'I'he  VG  I  S  acts  as  a  multiplexor,  handling  requests  from  clients  to  edit  data 
structures  representing  graphical  objects.  It  then  uses  a  real  terminal  protocol  to  actually  draw  the  objects  on 
the  screen. 

The  following  arc  stnne  attributes  of  the  VG’I’S  which  distinguish  it  from  related  work: 

•  The  VGTS  model  is  declarative  rather  titan  procedural.  Instead  of  describing  how  to  draw  a 
picture,  the  application  describes  what  is  to  be  drawn,  rite  user  then  specifics  where  the  picture 
should  be  displayed.  I  hus,  users  control  physical  tcnninals,  while  applications  control  virtual 
terminals. 

•  Objects  can  be  constructed  with  hierarchical  structure.  An  object  can  consist  of  primitives  or  calls 
to  other  objects,  which  can  in  turn  be  defined  in  terms  of  other  symbols.  This  is  in  contrast  to 
systems  like  (JKS  tliat  allow  only  one  level  orstiuclure(ustially  called  segments). 

•  The  VGTS  supports  true  device  independent  applications.  I'hcrc  is  a  standard  high-level 
interface,  called  the  Virtual  Graphics  lerminal  Protocol  (VG  I  P)  between  a  VG  I  S  and  its  clients. 
Different  terminal  drivers  exist  for  each  real  terminal,  with  die  VGTS  handling  all  the  details  of 
the  real  graphics  protocol. 

•  The  VGTS  implementation  and  interface  arc  portable  to  a  range  of  relatively  high-pcrfonnance 
devices.  This  contrasts  with  most  of  the  object-oriented  window  systems  that  arc  tailored  to  a 
specific  machine  or  language  environment. 

•  The  VG  I  S  supports  distributed  clients.  Applications  can  run  on  the  same  workstation  as  the 
VG  I  S,  on  another  workstalicni,  or  on  some  large  computation  server.  Since  tlic  communication  is 
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at  a  high  level,  the  different  machines  may  have  vastly  different  architectures.  If  the  application  is 
written  in  a  suitable  high-level  language,  the  same  source  code  is  used  in  any  location. 

•  A  single  user  can  access  several  different  applications  simultaneously.  The  user  can  switch 
contexts  between  these  applications  quickly  and  easily.  Because  of  the  ease  with  which 
applications  can  be  distributed  (the  previous  point),  they  can  be  using  the  local  workstation  or 
remote  computing  servers  at  the  same  time. 

These  last  two  aspects  arc  the  major  influence  of  the  distributed  heterogeneous  environment  on  the  VGTS. 
Timesharing  is  effective  when  many  users  must  share  a  computing  resource:  since  current  trends  indicate  that 
the  user  is  quickly  becoming  the  most  important  resource,  we  can  extrapolate  the  philosophy  that  users  arc 
more  important  tlian  machines,  and  have  one  user  being  served  by  several  different  computing  resources. 


3.2  The  User  Model 

In  the  modern  distributed  system  environment,  we  require  access  to  a  variety  of  applications,  distributed 
literally  tliroughout  the  world.  We  would  like  to  take  advantage  of  the  power  of  advanced  workstations  to 
provide  a  high-quality  user  interface  to  these  resources.  The  ideal  interface  must  take  into  account  four 
fundamental  principles: 

1.  The  interface  to  application  programs  should  be  independent  of  particular  physical  devices  or 
intervening  networks. 

2.  The  user  should  be  allowed  to  perform  multiple  tasks  simultaneously. 

3.  The  conimand  interaction  discipline  should  be  consistent  and  natural. 

4.  Response  to  user  interaction  should  be  fast 

The  first  principle  has  led  to  work  in  virtual  terminals  and  device-independent  graphics  packages;  the 
second  to  work  in  window  systems:  and  the  tliird  to  work  in  what  has  recently  been  called  user  interface 
management  .y’5/<’»/j[143].  the  most  common  examples  of  which  arc  command  languages.  Without  adhering 
to  the  fourth  principle,  however,  much  of  the  other  work  is  mrx)t.  Ideally,  human  users  should  never  have  to 
wait  for  the  computers;  the  computers  should  wait  for  the  user.  In  a  distributed  environment,  in  particular, 
die  supporting  network  prutcKuls  cannot  incur  inordinate  overhead. 


3.2.1  The  Ideal 

In  view  of  these  principles,  consider  the  following  user  model.  When  users  b(H)t  a  workstation  they 
communicate  with  a  view  manager^,  which  allows  users  to  authenticate  tlicmscivcs  and  initiate  one  or  more 
activities.  1110  activities  may  run  IcKal  to  tlie  workstation  or  rcinotc.  'nicy  may  be  written  with  tlic  particular 
workstation  in  mind,  or  run  in  ‘Terminal  emulation”  mode.  Ilicy  may  require  1/0  modalities  other  tlian 
traditional  one-dimensional  text;  graphics  or  audio,  for  example. 

Kach  activity  may  be  asscKiated  with  one  or  more  separate,  device-independent  virtual  terminals  (VI).  A 
Vr  may  be  created  by  tlic  user  or  by  tlic  activity  itself.  Hach  V  T  may  be  used  to  emulate  a  different  type  of 
real  tcnninal.  for  example,  a  page-mode  VT-lOO  or  a  3-n'  graphics  terminal.  Thus,  while  consistency  is 
encouraged,  the  user  is  still  able  to  access  all  resources  to  which  he  previously  had  access. 


Unfoiiun.itcly  nwny  similar  systems  refer  to  this  component  a.s  the  window  manger,  even  though  this  Ls  incorrect  with  respect  to  most 
terminology. 


ARCHi  rin  uitr.  oi- riir,  vg  ts 


29 


When  users  wish  to  initiate  a  new  activity,  they  must  first  create  a  new  executive,  llie  executive  acts  as  a 
command  interpreter  from  which  desired  activities  may  be  initiated.  Users  can  create  a  new  executive,  with 
an  associated  VI',  or  tenninate  an  existing  activity  and  VT  at  any  time,  that  is.  toUilly  asynchronous  to  any 
other  activities.  When  a  particular  activity  requires  additional  virtual  terminals,  it  is  free  to  create  them. 
I'hcsc  V  Ts  will  be  dcalkxraicd  when  the  activity  terminates. 

Virtual  terminals  arc  mapped  to  the  screen  when  and  where  tlic  user  desires.  In  fact,  multiple  screens  arc 
intentionally  allowed  by  the  architecture,  since  in  many  applications  color  or  grayscale  is  desired,  but  high 
resolution  color  monitors  arc  expensive.  I'luis  a  worksuition  may  have,  for  example,  one  low  resolution  color 
monitor  .ind  one  high  resolution  moncK'hromc  monitor.  Kjich  mapping  of  a  V'l’  to  the  screen  is  termed  a  view. 
When  an  .ictivity  creates  a  new  V  T,  it  prompts  the  user  to  specify  the  default  view  interactively,  or  tlic  view 
manager  ci  cates  the  view  automatically,  depending  on  user  preference  for  screen  layout,  riicrcaftcr,  users 
may  create  as  many  additional  views  as  they  wish,  riicy  may  manipulate  views  of  the  same  V  I’  independent 
of  all  other  views  of  that  V  T,  for  example,  to  pan  or  zoom  tlic  view. 

'nic  interaction  discipline  across  V  I  s  (and  hence  activities)  is  as  consistent  and  natural  as  possible.  ITie 
mechanisms  for  moving  between  V  i's  and  reorganizing  the  screen  arc  standardized  in  the  view  manager. 
Suindard  editing  facilities  permit  tlic  user  to  copy  text  or  graphics  from  one  VT  to  another.  A  standard 
command  interpreter  enforces  consistent  command  interpretation  across  applications.  A  variety  of 
inforniatiun  presentation  facilities  arc  provided  to  allow  the  user  to  view  and  manipulate  data  as  desired.  In 
fact,  different  representations  of  tlic  same  data  should  be  viewable  with  different  formats,  such  as  bar  charts 
of  data  contained  in  columns  of  numbers. 

Ultimately,  the  executive  mentioned  above  could  evolve  into  an  intelligent  agent  tliat  manages  the  user’s 
distributed  resources  in  much  tlic  same  way  a  traditional  command  language  interpreter  manages  a  single 
system's  resources  [78]  .  Then  and  only  then  would  the  user  be  totally  unaware  of  where  tlic  activities  arc 
actually  being  executed  -  local  to  the  workstation,  on  remote  hosts,  or  distributed  dynamically  between  some 
combination  of  workstations  and  hosts. 


3.2.2  Reality 

'I'his  thesis  focuses  on  virtual  terminal  management  issues,  with  particular  emphasis  on  distributed  graphics. 
I'hc  resulling  workstation  software  will  be  referred  to  as  the  Virtual  Graphics  Tcmiinal  Service  (VGl'S). 
Ilclow  we  will  consistcnliy  use  tlic  term  virtual  graphics  terminal  (VG  I )  in  place  of  virtual  terminal  to 
distinguish  it  from  more  traditional  work  in  network  virtual  terminals  and  window  systems  described  in  tlic 
previous  chapter.  'I'hc  VG  I  S  contains  both  a  graphics  package  and  a  window  system,  as  modules  in  the 
implementation  to  be  described  in  Chapter  4. 

Although  we  have  not  solved  all  tlic  problems  of  command  intcrciction,  simply  in  order  to  manipulate  the 
screen  we  have  developed  a  reasonable  command  interface  -  for  creating,  destroying,  and  rearranging  VG  Ts; 
managing  executives;  zooming,  etc.  In  addition,  many  of  the  common  command  interaction  techniques,  such 
a,;  menus  and  forms,  require  gr.iphical  support,  which  the  VG  I  S  is  can  provide.  In  sinn  t,  the  VG  TS  provides 
the  facilities  necessary  U)  experiment  with  a  variety  of  diflcrcnt  command  inlcrl'accs.  This  distinction  between 
tcnninal  management  and  command  interfaces  folUiws  from  previous  work  and  is  consistent  with  the  recent 
trend  towards  user  intcrfticc  management  systems  [78. 143].  t  he  rest  of  this  chapter  describes  the  VGTS 
architecture  in  detail. 
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3.3  The  NetworkGraphics  Architecture 

The  VGTS,  as  the  rest  of  the  V-System,  fits  the  classic  objeef  or  server  model  of  software 
architecture  (67, 155];  ITie  world  consists  of  a  collection  of  resources  accessible  by  clients  and  managed  by 
servers.  We  will  use  the  term  client  to  refer  to  any  entity  (a  human  user  or  program)  requesting  access  to  a 
resource.  We  will  use  tlic  tenn  user  lo  refer  exclusively  to  humans.  Architecturally,  we  make  few  assumptions 
as  to  how  servers  are  implemented  -  as  monitors  or  processes,  for  example.  The  current  implementation  is  in 
the  font!  of  tlie  message-based  V-System,  where  servers  are,  in  fact,  processes. 

For  the  purpose  of  terminal  interaction,  the  principal  resource  is  the  worksuition,  the  server  is  the  Yd'S, 
and  clients  consist  of  the  user  and  application  programs.  Figure  3-3  presents  the  interrelationships  among 
these  components.  Following  the  traditional  virtual  terminal  model,  applications  communicate  with  the 
VGTS  via  the  terminal-independent  virtual  graphics  terminal  protocol  (VG  I  F),  and  with  host  software  in 
whatever  way  necessary.  The  VGTS  communicates  with  the  hardware  via  the  terminal-dependent  real 
terminal  protocol  (RTV).  Thus,  the  VG  I’S  provides  a  protocol  translatioit  service  between  VGTF  and  RTF. 
Alternatively,  the  VG'IT  defines  the  interface  or  semantics  of  the  VGTS. 


User 


other  Services 


Figure  3-3:  High-level  VG  I  S  architecture 

In  terms  of  the  ISO  Reference  Mttdcl  for  computer  networking  (I6.^|.  the  VG  TF  is  a  prcsenuition  level 
proltKol.  Naturally,  when  used  across  a  network,  tlie  VG  I  F  must  be  encapsulated  in  appropriate  session  and 
transport  protocols.  We  refer  to  the  former  as  tlie  network  graphics  protocol  (NGF),  described  in  Section  3.5. 

In  terms  of  traditional  graphics  tenninology,  the  VG  TF  is  tlie  graphics  language  and  tlie  VGTS  implements 
the  graphics  package.  Together,  tlicy  olTcr  similar  functionality  to  a  number  of  existing  graphics  systems, 
including  those  conforming  to  die  ISO  standard  Graphical  Kernel  System  (GKS)(64j  and  the  proposed  Core 
sUindard  (147]  as  discussed  in  chapter  2.  The  VG  I  F  bears  an  even  greater  resemblance  to  die  proposed  FlIIGS 
standard  (4),  which  was  developed  at  approximately  the  siimc  time.  The  R  TF.  on  the  other  hand,  could  easily 
be  die  proposed  ANSI  Virtual  Device  Interface  (VDI)|122j  or  the  North  American  Fresentation  l.cvcl 
Frotocol  Syntax  (NAFLFS)  [6|. 
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3.4  The  Virtual  Graphics  Terminal  Protocol 

The  VGTS  has  two  very  different  protocol  interfaces:  one  to  the  user  and  one  to  the  client  application 
program.  First  we  will  discuss  in  detail  the  protocol  used  between  the  VG  I  S  and  its  clients,  referred  to  as  the 
VGTP  in  Figure  3-3.  Instead  of  standardizing  on  a  byte-stream  or  procedural  interface,  the  VGTP  was  first 
specified  as  kinds  of  objects  and  a  set  of  operations  on  tliose  objects.  This  section  describes  tliese  abstract 
operations,  and  the  next  chapter  discusses  how  the  operations  are  actually  implemented.  Figure  3-4  illustrates 
the  relationships  between  the  objects  discussed  in  this  section,  'nic  next  chapter  will  contain  a  concrete 
example  in  Figure  4-2  to  fiirther  explain  these  concepts. 
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f  igure  3-4:  Relationship  of  SI  )Fs,  VGTs,  and  Views 

llic  VG  I'S  provides  two  basic  types  of  structures:  structured  display  files  (Sl)F)  and  virtual  graphics 
terminals.  F\cry  graphical  object  is  delineil  within  a  specific  SDF:  thus,  an  SDF  rcpiesents  an  object 
definition  space.  In  order  to  view  an  object,  it  is  necessiiry.  first,  to  ass(X.'iatc  the  object's  SDF  definition  with 
a  VG  r  (by  the  program)  and,  second,  to  specify  a  mapping  of  die  VGT  to  the  screen  (by  tlie  user). 


3.4.1  SDFs  and  their  Manipulation 

An  SDF  consists  of  a  collection  of  iicnis.  The  items  can  be  either  primitives,  or  grouped  into  symbols,  which 
can  in  turn  be  contained  in  instances  of  other  symbols,  to  any  desired  depth.  I'he  SDF  forms  a  directed 
acyclic  graph  (DAG),  with  items  as  nodes  of  the  DAG.  Abstractly,  symbol  definition  mxics  have  arcs  to  all 
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their  component  items.  Symboi  cull  nodes  have  ates  to  the  symbol  dcrinition  node,  and  primitive  items 
correspond  to  leaf  nodes. 

An  SDF  is  similar  to  a  segment  network  in  PlliGS.  while  an  item  is  equivalent  to  an  element  [4].  An  SDF 
may  also  be  thought  of  as  a  symbol  system  [56].  Items  arc  named  by  identifiers  chosen  by  the  application,  are 
typed,  and  have  type-dependent  attributes.  The  ranges  of  tltcsc  identifiers  and  attributes  will  be  discussed  in 
Section  4.3.  Item  types  include: 

•  line 

•  (filled)  rectangle 

•  (filled)  polygon 

•  bitmap 

•  text  (in  arbitrary  fonts) 

•  (filled)  spline 

•  symbol  definition 

•  symbol  call 

All  items  arc  defined  within  a  2  dimensional  integer  world  coordinate  space.  Translation  is  the  only  modeling 
transformation  pcnniltcd  on  “called”  symbols.  All  other  transformations,  such  as  rotation  or  projection  from 
higher  dimensions,  arc  presently  handled  by  titc  application  program.  Attributes  are  specified  as  indices  into 
type-specific  uiti  ibutc  tables  similar  to  the  bundled  attrihuics  of  GKS.  However,  these  attribute  tables  are 
shared  by  all  VGTs  and  managed  by  the  VG'I'S  in  its  role  as  mediator  between  simultaneous  applications.  In 
contrast,  GKS  allows  tlic  single  application  to  control  tlic  bundle  tables.  VG1'S  attributes  arc  specified  (at 
least  indirectly)  on  each  item,  not  inherited  from  calling  symbols,  as  they  are  in  PlliGS,  for  example,  or  set  by 
modes. 

A  client  can  create  and  delete  structured  display  files,  symbols,  or  items.  It  may  edit  symbols,  and  obtain  or 
change  the  properties  of  an  item.  The  following  functions  arc  provided  to  manipulate  the  SDF; 

CreateSDFO  =>sdf 

Create  a  structured  display  file,  and  return  its  identifier  in  sdf.  Tliis  must  be  done  before  any  symbols 
arc  defined. 

DeteteSDF  (sdfl 

Return  all  tlic  items  defined  in  the  given  sdf  to  free  storage. 

DefineSymbol(sdf,  item,  name) 

iMitcr  a  symbol  into  tlic  symbol  table,  and  open  it  for  editing.  'ITic  sdf  is  one  returned  from  a  previous 
Creates DF call,  item  is  an  application-specific  integer  identifier  for  the  symbol  and  mme  is  an  optional 
string  name. 

EndSymbot  (sdf.  item,  vgt) 

CUisc  symbol  item  in  sdf  so  no  more  items  can  be  changed,  and  cause  the  vgt  to  be  redrawn  to  reflect  the 
new  sdf.  Called  at  tlic  end  of  a  list  of  items  defining  a  symbol,  started  with  CreateSymbol  or 
EdiiSymboL 

EditSymbol  (sdf.  item) 

Open  existing  symbol  item  in  sdf  for  modification.  ITiis  has  the  effect  of  calling  DefineSytnbtd  and 
inserting  all  tlic  already  existing  entries  to  the  definitions  list  Ilic  editing  process  is  ended  in  the  same 
way  as  the  initial  definition  process;  a  call  to  EiidSymboL 

DeleteSynib<d(sdf  item) 

Delete  the  definition  of  symbol  item  from  sdf.  Any  dangling  instances  of  this  symbol,  created  by 
AddCall.  will  remain,  but  will  contain  nothing. 
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AddCall(sdf.  item,  offset,  calledSyinbul) 

Add  an  instance  of  caUedSymbol  to  the  currently  open  syntbol  in  the  sdf.  The  instance  is  given  the 
name  item.  The  called  symbol’s  origin  will  be  placed  at  offset  in  the  calling  symbol’s  coordinate  space;  it 
is  not  windowed  or  transformed  in  any  other  way,  ITiis  is  equivalent  to  a  move  call  unit  in  Sproull  and 
niomas’s  structured  format  protocol  [126],  or  an  Execute  c&\\  in  NGS.  as  opposed  to  a  Copy  caW.  That 
is,  changing  die  symbol  definition  changes  all  inswnces.  This  is  more  like  a  subroutine  call  than  a  macro 
expansion. 

Addltem  (sdf,  item,  extent,  type,  attributes,  typeData) 

Add  an  item  to  the  currently  open  symbol  in  tlie  sdf,  giving  it  die  name  item,  extent  specifics  the 
bounding  box  of  die  item  in  its  coordinate  space,  type  and  attribute  dctcminc  the  type  and  attributes 
respectively.  /j/ir/Ju/rt  contains  any  other  data  needed  to  define  the  item,  such  as  the  control  points  for 
a  spline  item  or  the  text  string  for  a  text  item. 

Deleteltem  (sdf,  item) 

Delete  item  from  the  currently  open  symbol  definition  in  sdf. 

Inquireltem  (sdf.  item)  -  >  extent,  type,  attributes,  typeData 
Return  the  parameters  for  item  in  sdf. 

tnquireCall (sdf.  item)  =  >  calledSymbol 

Return  die  item  name,  calledSymbol,  of  the  symbol  called  by  the  item  in  sdf. 

Change  Item  (sdf,  item,  extent,  type,  attributes.  typeData) 

Change  the  parameters  of  an  already  existing  item  in  sdf.  'I’his  is  equivalent  to  deleting  an  item  and  then 
reinserting  it.  so  the  item  must  be  part  of  the  open  symbol. 

3.4.2  VGT  and  View  Management 

Once  the  VG  I'S  client  has  defined  some  graphical  objects,  the  client  or  the  user  needs  to  provide 
infonnation  on  how  the  objects  should  appear.  The  VG  I'S  lets  a  user  sec  objects  in  any  VG  T  anywhere  on 
the  screen  in  views.  Hath  view  has  a  /(Kim  factor,  a  window  on  the  world  coordinates  of  the  VG  I',  and  screen 
ctKirdinates  which  determine  its  viewport.  I'luis.  a  view  defines  a  particular  viewing  transfonnation  directly 
from  world  to  device  coordinate  space.  No  intennediate  transfonnations,  such  as  normalized  device 
coordinates,  arc  visible  to  the  client. 

Although  the  client  can  create  default  views,  the  user  can  change  them  with  the  view  manager,  and  create 
and  destroy  more  of  dicin.  liach  VG  f  can  exist  in  zero  or  more  views,  but  each  view  has  exactly  one  VGT 
associated  with  it.  Dich  VG  T  is  asstKiated  with  at  most  one  SDF,  but  each  SDF  may  be  associated  with 
several  VGTs.  Symbol  definitions  arc  shared  between  VG  Ts  that  have  the  stimc  SDI*.  Thus  one  VG  T  can 
display  at  its  top  level  a  symbol  that  appears  as  a  called  instance  at  a  lower  level  in  some  other  symbol  in 
another  VG  T. 

Functions  for  clients'  manipulation  of  VG  I  s  and  views  include: 

CreateVCT (type,  name,  sdf  item)  =>  vgt 

Create  a  VGT  of  type  type  and  return  its  identifier  in  vgt.  name  is  a  clicnt-spccificd  symbolic  name  for 
the  VG  r  that  may  be  used  later  to  select  tliat  VG  T  for  input,  item  in  sdf  iti  placed  as  the  top-level  item 
in  Uic  VG  T;  it  can  be  zero  to  indicate  an  initially  blank  VGT.  I’hc  type  can  be  some  combination  of 
Text.  Graphics,  and  Zoonmble. 

Destroy  VGT  ( vgt) 

Destroy  the  given  vgt  and  all  the  associated  views. 
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DefauItView (vgt,  width,  height,  wXmin,  wYmin,  zoom,  showGrid)  =>  width,  height 

Create  a  view  of  the  given  display,  with  die  user  determining  the  position  on  die  screen  with  the 
graphical  input  device,  width  and  height  give  the  initial  size  of  the  view;  non-positive  values  indicate 
that  the  user  should  determine  the  size  dynamically,  in  which  case  the  selected  values  arc  returned. 
wXniin  and  wYmin  arc  the  world  coordinates  to  map  to  the  left  bottom  corner  of  the  viewport;  the 
amount  of  the  world  actually  viewed  depends  on  the  size  of  the  viewport  and  the  zoom  factor.  ’ITic 
zoom  factor  is  the  power  of  two  to  multiply  world  coordinates  to  get  screen  ccnirdinatcs;  it  may  be 
negative,  to  denote  that  a  view  is  zoomed  out.  Views  arc  not  otherwise  transformed.  If  shoviGrid  is  set, 
a  grid  of  points  is  displayed  in  the  viewport 

To  display  a  new  graphical  object  in  a  VGT  after  the  VGT  is  created,  cither  the  old  top  symbol  can  be 
edited,  or  a  new  symbol  can  be  defined  and  the  following  function  called; 

Display  Item  (vgt.  sdf,  item) 

Change  the  top-level  item  in  vgt  to  be  item  in  sdf.  'I'he  new  item  is  displayed  in  every  view  of  the  VGT. 

DefauItView  executes  an  implicit  Display  Item  after  creating  the  view.  EndSymbol  may  also  cause  output  to 
appear  after  (rcjdefining  a  symbol,  although  the  VG  I  S  redraws  only  the  part  of  the  view  that  has  changed  in 
this  case.  I'he  VGTS  implementation  is  also  free  to  perform  other  optimiziilions,  such  as  only  drawing  the 
additional  items  if  the  only  changes  before  an  EndSymbol  arc  adding  top-level  primitives.  Using  these 
functions,  the  VGTS  client  can  achieve  the  effect  of  deferral  modes  for  graphical  output,  including; 

batch  Construct  the  graphical  object  in  its  entirety  and  then  display  it,  by  executing  a 

DefineSymbol  or  EditSymbol,  many  Additem  calls,  followed  by  an  EndSymbol  call.  ITiis 
corresponds  to  creating  an  invisible  segment  and  making  it  visible,  or  using  the  At  Some 
Time  deferral  mode  in  GKS. 

incremental  Construct  and  display  the  object  “on  the  fly”,  that  is,  display  each  primitive  item  (each 
vector,  for  example)  as  It  is  added  to  the  object,  by  repeatedly  executing  an  EditSymbol, 
Additem,  EndSymbol ^ccpscncc.  This  corresponds  to  creating  a  visible  segment,  using  the  As 
Soon  As  Possible  deferral  mode  in  GKS. 

The  latter  approach  may  achieve  better  response,  and  is  the  normal  mode  of  operation  for  most  traditional 
graphics  systems.  However,  as  results  will  show,  the  former  metliod  usually  achieves  higher  throughput,  and 
is  the  norm  for  programs  using  the  V.G'l'S. 


3.4.3  Input  Event  Management 

Since  the  VG  I’S  was  designed  to  support  multiple  simultaneous  clients,  it  must  decide  which  client  receives 
which  input  events.  This  is  called  input  demultiplexing,  and  naturally  occurs  on  a  VG  T  basis.  'Hie  following 
ftmetions  arc  available  for  graphical  input: 

Get  Event  (vgt.  event  Mask)  ->  event  Descriptor 

Wait  for  an  input  event  to  occur  with  respect  to  tlic  indicated  vgt  and  return  a  variant  record  in 
event  Descriptor  that  describes  the  event.  I'he  record  will  contain  Uic  type  of  the  event  and  tlic  relevant 
type-dependent  information,  event  Mask  specifics  the  acceptable  types  of  input  events:  keyboard  or 
mouse.  Ihc  mouse  events  subsume  button  and  Iwator  devices  of  GKS.  returning  the  buttons  pressed 
and  the  location  in  virtual  coordinates  within  the  vgt.  I’he  first  event  in  any  of  tlic  indicated  classes  to 
(xrcur  is  returned. 

FindSelectedObject  (event Descriptor,  searchType)  =>ilem,  edgeSet 

Given  an  event  descriptor  as  returned  by  GetEvent.  return  tlic  item  of  the  smallest  object  near  the 
event,  and  a  set  of  (I  .eft.  Right,  'lop.  Ilottom)  edges  which  the  event  was  near. 
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GetGmphksStatus  ( vgl)  -  >  status 

Return  the  status  of  the  graphical  input  device  with  respect  to  the  indicated  vgt  including  buttons 
pressed  and  location.  As  a  side  effect,  the  event  queue  is  cleared  of  any  outstanding  graphical  events. 

PopUp(n\cnu)  =>  selection 

Display  a  menu  of  choices  at  the  cursor  position,  consisting  of  an  array  of  su-ings,  to  the  user.  When  the 
user  selects  a  particular  item,  return  the  array  index  in  selection.  I  his  is  similar  to  tlic  GKS  choice 
device. 

GetEvent  Md  GetGraphicsStatus  iogeiher  provide  the  fimctionality  of  tlic  GKS  input  modes.  The  VG'PS 
maintains  an  event  queue  for  each  VG  1';  all  keyboard  and  mouse  events  related  to  tliat  VG  1'  arc  queued  in  the 
same  queue,  in  l  iret-In-l-irst-Out  order,  l  luis  the  event  mode  of  GKS  is  supported  for  both  the  keyboard 
and  mouse  tlirough  GelEvent.  Pick  device  functionality  is  obtained  from  die  FindSelectcdObjcct  function, 
which  is  similar  to  request  mode  of  GKS.  GetGraphicsStatus  allows  the  mouse  to  operate  in  sample  mode. 
Sampling  of  the  keyboard  is  not  supported,  since  such  a  capability  would  be  quite  device  dependent 

Keyboard  input  is  always  associated  with  some  VG'f  group.  Hach  VG'I'  belongs  to  exactly  one  group,  and  a 
group  typically  corresponds  to  an  activity  (although  an  activity  can  create  multiple  groups).  I'hc  groups  are 
identified  by  their  master,  which  receives  keyboard  input  when  the  group  is  selected  Uirough  the  user 
interface.  The  next  section  describes  the  textual  output  interface,  provided  so  the  simple  symmetric  model  of 
standard  terminals  can  be  used  for  echoing  keyboard  input 

3.4.4  Text  Terminal  Emulation 

Ibc  VGTS  supports  a  text  VGT  mode  optimixed  for  page-mode  terminal  emulation.  Specifically,  an 
application  may  treat  a  VG  T  as  a  standard  ANSI  terminal  [1],  such  as  a  DHC  V'l'-lOO.  Such  an  application 
need  not  know  anything  about  the  graphical  facilities  of  the  VGTP,  and  may  use  the  Ansi  terminal  protocol 
to  communicate  with  the  VG  I  S,  including  escape  sequences  for  cursor  control.  Output  to  the  VG  T  is  stored 
in  a  /j</J(77|,  which  is  a  symbol  within  an  SDK.  The  symbol  consists  of  a  linear  array  of  simple  text  items, 
each  of  v/hich  represents  one  line. 

Note  tliat  the  terminal  emulation  output  interface  is  of  a  different  nature  from  (and  therefore, 
unfortunaicly.  incompatible  with)  the  graphics  interface  as  discussed  above.  I  lowcvcr,  this  docs  not  prevent  a 
mixed  toxl  and  graphics  application.  One  particular  type  of  graphics  item  is  text,  pcrmilting  a  client  to  easily 
integrate  text  and  graphics  within  a  graphics  VG  T,  The  terminal  emulator  interface  is  provided  to  optimize 
performance  for  a  typical  special  case. 

I'hc  VG  rS  architecture  provides  several  advanced  features  for  the  support  of  keyboard  input  processing. 
Applications  can  operate  in  “raw"  mode,  or  selectively  enable  any  of  tlic  following  features: 

Local  Hello  I  bis  allows  instant  response  to  keyboard  input,  providing  useful  feedback  to  users  of 
potentially  loaded  timesharing  systems. 

Line  Hdiiing  Programs  that  interact  on  a  line-by-line  basis,  such  as  the  executive,  can  cause  lines  to  be 
buffered  (and  usually  echoed)  inside  the  VG  I'S.  Sophisticated  editing  commands  arc 
available  on  the  line  bufTcr,  and  the  executive  (for  example)  can  “stufT'  previous  command 
lines  into  die  line  buffer,  in  conjunction  with  its  history  mechanism. 

Paged  Output  When  this  mode  is  in  effect,  the  VG  I  S  will  block  output  requests  larger  dian  one  page,  A 
message  is  displayed  in  the  banner,  and  the  user  types  a  command  to  unbltKk  when  ready. 

Graphics  Hscapes  Inside  a  pad,  when  connected  to  some  remote  hosts  through  a  ri:i  Ni:i'  program,  graphical 
input  events  can  send  escape  sequences  back  to  the  application.  This  allows  many  useful 
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programs  that  deal  with  conventional  terminals  to  be  simply  extended  to  take  advantage  of 
graphical  input  capability  without  major  redesigns  of  the  applications.  For  example,  an 
F,macs(129]  library  can  be  loaded  to  bind  these  character  strings  to  commands  that 
position  the  text  cursor,  set  the  Emac’S  mark,  delete  and  insert  text. 

By  default,  keyboard  input  is  line-buffered  and  echoed  by  the  VCfS.  with  the  powerful  line-editor  built  in. 
Support  for  text  editing  by  a  pointing  device  could  be  provided,  transparently  to  applications.  This  has  been 
partially  implemented  in  one  user’s  custom  version  of  the  VGTS. 


3.5  The  VGTS  Client  Protocols 

The  VG'I  P  is  constant  over  all  applications,  but  allows  for  a  wide  variety  of  bindings  to  lower-level 
protocols.  Some  applications  have  no  knowledge  of  the  VGTP  and  some  applications  arc  running  on 
machines  that  do  not  support  the  interprocess  communication  mechanisms  underlying  the  VGTP.  Whenever 
the  application  is  running  remotely,  the  VG'IT  must  be  encapsulated  within  an  appropriate  network  transport 
protocol.  The  following  situations  arise  (see  Figure  3-5,  in  which  each  inter-machine  arc  is  labeled  with  an 
example  (presentation  protocol,  transport  protocol)  pair): 


Figure  >5:  Possible  clients  of  the  VGTS 

•  Application  A  mns  on  the  workshition  and  communicates  via  V  kernel  mcssjigcs.  Current 
examples  include  text  editors,  diKumcnt  illustrators,  and  design  aids. 

•  Application  B  and  tlic  VG'I'S  run  on  two  separate  machines  that  support  network-transparent 
interprocess  communication,  such  as  the  V-System  intci^kerncl  protocol  (\K?),  B  communicates 
with  tlic  VG  I  S  via  tlic  VG  TP.  as  in  the  ease  of  a  application  A. 
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•  Application  C  runs  on  a  machine  that  docs  not  support  network-transparent  IPC,  but  docs 
support  a  traditional  network  architecture.  In  addition,  a  VG  I’P  interface  package  is  available  tJiat 
encapsulates  the  VG  I  P  within  tlic  appropriate  transport  protocol.  Similarly,  a  local  agent  for  the 
application,  C\  is  created  on  the  workstation  to  dccapsulatc  the  VG  TP.  "Ihus,  the  application  may 
still  be  written  in  terms  of  the  VG  I  P  and  ncitlier  it  nor  the  VG'l'S  have  any  knowledge  that  the 
other  is  remote.  Our  V1.S1  layout  editor,  for  example,  can  be  run  in  this  fashion  under 
Vax/Unix. 

•  Application  Dhas  no  knowledge  of  the  VGT  S  or  the  VGTP;  it  wishes  to  regard  the  workstation  as 
just  another  terminal.  The  local  agent,  D\  is  “user  Telnei"  and  performs  the  appropriate 
translations  between  T’elnei'  and  VGT’P. 

•  Application  E  is  distributed  between  die  workstation  and  one  or  more  other  machines.  TTie  local 
agent,  E\  is  responsible  for  communicating  between  the  distributed  parts  of  tlic  application  and 
tlic  VGT  S.  It  must  perform  tlic  appropriate  set  of  protocol  conversions  indicated  above.  In 
addition,  it  may  wish  to  perform  application-specific  fiinctions,  such  as  high-level  caching.  In  that 
ease,  the  protocol  used  to  communicate  with  the  remote  applications  may  require  more  than 
simple  transport  service. 

All  applications  but  A  use  a  network  transport  protocol,  whether  they  realize  it  or  not.  Application  B 
employs  an  interprocess  communication  protocol  that  has  nothing  to  do  with  graphics  per  se.  Application  D 
employs  a  proUKol  tliat  in  no  way  depends  on  knowledge  of  the  VGT  S  and  typically  has  nothing  to  do  with 
graphics;  in  order  to  run,  an  appropriate  protocol-converter  must  run  on  the  workstation. 

Applications  Cand  E,  on  the  other  hand,  know  all  about  the  VGTS  and  are  very'  interested  in  graphics.  We 
will  refer  to  the  protocol  tlicy  employ  as  the  network  graphics  protocol  (NGP).  TTie  NGP  may  be  a  simple 
encapsulation  of  die  VGT'P  by  an  existing  transport  protocol,  it  may  be  a  problem-oriented  protocol  [117],  or 
it  may  itself  be  a  multi-level  protocol.  Application  C,  for  example,  may  find  a  direct  encapsulation  of  the 
VGT'P  acceptable.  Application  £.  however,  may  wish  to  maintain  a  replicated  database  (the  main  database 
plus  the  cache),  or  may  wish  to  trade  reliability  against  cost.  In  diese  cases,  the  NGP  offers  considerably  more 
functionality  than  mere  encapsulation/dccapsulation  of  the  VGTP.  In  general,  the  VG  TP  and  NGP 
correspond  roughly  to  presenuition  and  session  layer  protocols,  respectively,  in  the  ISO  reference  model  [163], 
Ilie  transport  protocols  used  in  the  prouuype  implementation  are  discussed  in  Section  4.3.5. 

3.6  Summary  and  Implications  of  the  Architecture 

This  chapter  presented  a  high-level  virtual  graphics  terminal  protocol  that  is  the  key  element  of  the  VGTS 
architecture.  This  protocol  is  used  by  applications  to  specify  graphical  objects  with  hierarchical  structure. 
I'hc  use  of  suindard  proUKols  helps  to  provide  device  independence.  Any  application  program  which  uses 
the  sumdard  protixrol  can  be  used  with  any  implementation  of  the  VG  I  S.  without  any  modifications.  More 
information  about  how  this  is  achieved,  and  other  details  of  the  prototype  implementation  are  given  in  the 
next  chapter.  Chapter  5  discusses  the  rationale  behind  tlie  design  of  both  the  architecture  and  the 
implementation,  including  why  the  design  facilitates  distribution  and  concurrency.  As  will  be  shown  in  the 
Chapter  6.  this  protiKol  is  successful  in  limiting  both  the  frequency  of  communication  between  application 
and  VG  rS  and  tlic  amount  of  data  transmitted  at  any  one  time. 
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An  Implementation  of  the  VGTS 

The  architecture  described  in  the  previous  chapter  is  independent  of  any  implementation.  Programs 
developed  for  one  implementation  of  tlic  VG  I  S  should  be  able  to  run  with  any  other  implementation,  given 
the  existence  of  the  appropriate  transport  protocols.  In  this  chapter  we  will  first  describe  the  organization  of 
one  particular  prototype  implementation.  'I’his  implementation  aetually  adapts  itself  at  run-time  to  several 
different  varieties  of  workstations,  and  many  modules  can  be  used  on  other  very  different  workspitions.  The 
techniques  used  in  this  implementation  to  update  the  screen  arc  discussed,  followed  by  the  client  interface, 
and  tlien  the  user  interface.  Finally,  an  example  application  program  is  described:  a  simple  illustration 
editor. 

4.1  General  Organization 

As  noted  in  Section  3.2,  the  VGTS  is  only  one  component  of  the  user  interface  software  in  the  V-System. 
The  other  components  are; 

•  the  view  manager 

•  the  exec  server 

•  tlic  executives 

•  the  application  library 

The  view  manager  provides  the  means  by  which  users  can  create,  destroy,  and  modify  the  screen  layout,  as 
well  as  create  new  executives.  Kxccutivcs  represent  insuinccs  of  tlic  same  basic  comma.id  interpreter,  as 
defined  by  tlic  exec  server.  To  create  a  new  executive,  the  user  communicates  with  the  view  manager,  which 
communicates  with  tlic  exec  server,  llic  user  may  replace  the  exec  server  at  any  time,  cffc:livcly  redefining 
the  executive  command  interpreters.  Logically,  the  view  manager  is  another  module  tliat  may  be  replaced. 
Ultimately,  however,  these  components  employ  the  services  of  the  VG  IS  to  communicate  with  the  user. 

In  fact,  the  VG  I  S  is  merely  an  instance  of  a  lenninal  ageni.  Hence,  the  user  may  also  replace  the  VGI'S  at 
any  time  with  simpler  terminal  agents,  or  other  window  systems.  This  facility  permits  a  programmer  to 
develop  new  graphics  facilities  without  having  to  constantly  rebtHit  his  workstation.  On  the  other  hand,  it 
provides  the  mechanism  by  which  the  s;imc  user  interface  management  system  can  communicate  with  a 
subsUintially  "reduced"  terminal  agent  such  as  Uic  simple  terminal  server  (S  TS),  a  subset  of  tlic  VGTS 
architecture  which  runs  on  a  simple  text-only  terminal  [17]. 

4.1.1  VGTS  Implementation  Modules 

At  one  more  level  of  dcUiil.  each  terminal  agent  is  composed  of  multiple  components.  In  particular,  tlic 
VG  I  S  implementation  consists  of  the  following  modules: 

master  multiplexor  Handles  all  client  requests  by  dispatching  to  the  appropriate  routine  in  other  modules. 

Provides  synchronization  between  all  tlic  possible  clients,  by  receiving  mcssiigcs  from 
them.  The  major  part  of  the  operating  system  interface  is  contained  in  this  module. 

escape  interpreter  Monitors  the  incoming  byte  stream  for  graphics  commands  and  calls  tlic  SDF 
manager  to  perform  tlicm.  Other  chariictcrs  arc  passed  tlirough  to  tlic  tcnninal 
emulator. 

terminal  emulator  Interprets  a  byte  stream  as  if  it  were  an  Ansi  standard  terminal  [1].  Printable 
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Figure  4- 1 :  Process  and  module  structure  of  die  VG'FS 

characters  are  added  to  text  objects,  and  control  and  escape  codes  are  mapped  into  the 
proper  VG  I  P  operations. 

SOF  manager  Handles  requests  to  create,  destroy,  and  modify  graphical  objects  within  structured 
display  files.  Maximum  extents  of  symbols  arc  maintained  to  help  die  redrawing 
process.  I'his  is  cITectivcIy  the  Jisphty  file  (y;/»/»//<T[27,  5()J.  Included  is  a  hash  Uiblc 
manager  to  keep  track  of  symbol  definitions  and  item  numbers. 

SDF  intcrpictcr  Highest-level  graphical  output  operations,  llic  structured  display  file  is  visited 
recursively,  with  appropriate  clipping  for  extents  totally  outside  the  area  being  drawn. 
This  is  effeedvely  die  display  processing  unit.  In  a  higher-performance 
implementation  this  module  and  the  ones  below  it  could  be  implemented  in  hardware. 


hit  detection 


'Hie  stmetured  display  file  is  visited,  but  instead  of  .actually  drawing  the  primitives,  the 
positions  arc  checked  to  match  die  cursor's  position.  A  list  of  possibly  sclated  objects 
(under  other  optional  constraints)  is  returned  to  die  client. 
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event  handler  Handles  the  event  queues,  line  buffering,  and  the  blocking  and  unblocking  of  clients 
waiting  on  events. 

view  manager  Provides  the  user  interface  for  screen  management.  Although  this  is  logically  a  fairly 
separate  entity  from  the  lower-level  functions  of  the  VGl'S,  in  the  current 
implementation  it  is  provided  as  a  module  which  runs  as  a  coroutine  to  the  master 
multiplexor  process. 

view  primitives  Perfomi  the  view-changing  operations.  I'hese  arc  the  operations  invoked  by  the  view 
manager,  such  as  creating,  deleting,  and  modifying  views. 

display  manager  Low-level  but  possibly  device-independent  operations,  such  as  handling  die 
overlapping  viewports.  Although  this  module  does  not  do  any  frame  buffer 
operations  directly,  it  uses  several  dcvicc-dcpcndcnt  parameters,  such  as  the  size  of  the 
screen  in  physical  coordinates.  Also,  some  of  these  operations  could  be  done  in 
hardwaie  on  highcr-pcrformancc  graphics  devices. 

drawing  manager  Device-dependent  graphics  primitives  called  by  the  display  manager.  On  the  SuN 
worksuition,  for  example,  these  primitives  manipulate  tlic  frame  buffer.  On  other 
lower-performance  workstations  this  might  be  done  by  a  separate  process  to  prevent 
the  multiplexor  process  from  blocking  for  long  periods  of  time. 

input  handlers  Dcvicc-dcpcndcnt  modules  for  reading  the  keyboard  and  tracking  the  mouse.  There 
is  also  a  timer  module  to  supply  periodic  messages  to  the  multiplexor. 

'I’hc  relationships  between  these  modules  arc  illustrated  in  Figure  4-1.  The  general  direction  of  control  is 
indicated  by  the  direction  of  the  arrows.  The  higher  level  modules  near  the  top  of  the  figure  call  lower  level 
modules  near  die  bottom. 

4.1 .2  Team  and  Process  Structure 

'Hie  V-System  provided  three  techniques  for  structuring  software:  modules,  processes,  and  teams. 
Modules  arc  groups  of  functions  that  communicate  through  function  calls  and  global  variables,  'nic  kernel 
manages  independent  ciincurrent  processes,  which  communicate  tlirough  messages  or  shared  memory.  Only 
pr«x:es.scs  on  die  same  team  share  memory;  separate  teams  arc  separate  virtual  address  spaces.  Ilic  process 
structure  of  die  VGTS  is  also  illustrated  in  1-igurc  4-1,  by  die  presence  of  the  thick  arrows.  The  arrows  arc 
drawn  in  the  direction  diat  mcssiigcs  arc  sent,  from  the  sender  to  die  receiver.  The  VG  I  S  implementation 
consists  of  four  processes: 

1.  llic  keyboard  helper  process  reads  from  the  kernel  console  device  and  sends  messages  to  the 
master  multiplexor. 

2.  Ilie  mouse  helper  reads  from  the  kernel  mouse  device  and  sends  mcssiigcs  to  the  master 
multiplexor. 

3.  I’hc  timer  helper  delays  for  set  period  and  sends  timing  messages  to  die  master  multiplexor. 
Several  activities  arc  triggered  by  these  mcs.s;igcs.  including  a  blanking  of  the  screen  after  ten 
minutes  if  no  other  mcssiigcs  have  been  received. 

4.  'Hie  master  multiplexor  process  synchronizes  all  frame  buffer  operations,  and  performs  most  of 
the  other  functions. 

'Ihc  low  level  interface  to  the  console,  mouse,  and  timer  is  implemented  by  the  V  kernel.  Normal  messages 
arc  sent  to  a  pseudo-process  called  the  "device  server"  which  will  block  until  daUi  is  available.  This  blocking 
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necessitates  the  three  extra  helper  processes  for  these  devices.  The  main  loop  of  the  VG'I'S.  like  most  servers 
in  the  V-System,  consists  of  a  Receive  primitive  followed  by  a  switch  on  the  type  of  request.  The  main 
process  of  the  VGTS  should  never  block  for  significant  periods  of  time. 


4.1.3  Module  Sizes 


The  number  of  lines  of  source  and  the  number  of  bytes  for  object  code  for  each  of  the  modules  is  given  in 
fable  4-1.  The  “Others”  line  refers  to  lines  of  code  in  the  header  files,  and  bytes  obtained  from  libraries. 
Note  that  about  one  third  of  the  object  code  is  obtained  from  libraries.  Another  interesting  observation  on 
the  relative  sizes  of  modules  is  that  the  module  that  is  largest  in  source  and  second  largest  in  object  code 
(spline  and  polygon  fiinctions)  is  very  rarely  used. 


Module 

Source  Size 
(I.incs) 

Object  Size 
(Bvtes) 

Display 

442 

3475 

Splines  and  Polygons 

1498 

10068 

SUN  Drawing  Manager 

1423 

8860 

Event  Handler 

1150 

6540 

SDF  Interpreter 

638 

6540 

F^ape  Interpreter 

594 

5164 

Input  Handlers 

427 

2416 

View  Manager 

1137 

9920 

Hit  Detection 

983 

6024 

Ma.stcr  Multiplexor 

1045 

8212 

'ferminal  Emulator 

896 

6000 

SDF  Manager 

1349 

14240 

View  Primitives 

1209 

8676 

Others 

425 

51059 

Total 

13283 

140654 

Table  4*1:  VGTS  implementation  module  sizes 


4.1.4  Adaptive  Techniques 

The  VG'I'S  uses  several  techniques  to  adapt  to  its  environment.  First,  several  link-time  versions  are 
available.  In  tlie  full  configuration,  tlic  basic  V-System  services  (such  as  tlic  exec  server,  context  prefix  server, 
team  server,  exception  server,  etc.),  are  provided  by  one  team,  which  loads  another  team  at  initialization 
consisting  of  the  VG  I  S  and  a  default  view  manager,  Ihc  user  can  then  issue  a  command  to  repl.ice  the  entire 
VG  I S  and  view  manager  al  run  time.  Since  this  capability  is  rarely  used  except  by  some  VG  I  S  developers, 
another  configuration  has  the  VG  I  S  linked  together  with  the  basic  services  into  a  single  team.  The  two-team 
version  Uikcs  longer  to  load,  and  occupies  at  least  50K  byte's  more  of  memory  and  another  team  descriptor, 
l-inally.  for  systems  that  are  short  of  memory,  a  reduced  functitm  VG  I  S  is  available  with  no  splines,  polygons, 
or  font  loading  facilities. 

The  low-level  VG  I  S  device  driver  has  to  deal  with  subtle  difTcrcnccs  among  the  many  versions  of  SUN 
workstation  hardware  that  have  evolved  over  the  years.  Some  differences  are  handled  by  tlie  V  kernel  device 
server,  which  provides  virtual  keyboard  and  mouse  devices.  Other  parameters,  such  as  the  exact  screen  size 
(which  varies  from  796  lines  by  1024  pixels  to  1024  lines  by  800  pixels)  and  the  virtual  address  of  the  frame 
bulTcr,  are  dclcnnined  at  run-time  with  the  aid  of  a  kernel  worksUititm  query  operation. 

More  changes  were  required  to  support  an  implementation  of  the  VG  fS  for  a  later  model  of  the  SUN 
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workstation,  called  tlic  SUN-2.  Initially  the  single  installed  VGTS  would  query  the  kernel  on  start-up  to 
determine  tlie  type  of  frame  buffer  and  set  a  variable.  This  variable  was  tested  before  each  primitive  to 
detennine  which  low-level  graphics  function  to  call.  Altliough  the  run-time  CPU  overhead  was  acceptable, 
the  memory  usage  of  the  combined  version  eventually  prompted  the  split  into  separate  vereions  for  the 
SUN-1  and  SUN-2  frame  buffei's.  Interestingly,  the  mere  act  of  identifying  device  dependencies  tliat  had 
crept  into  modules  that  were  previously  tliought  to  be  device  dependent,  resulted  in  cleaning  up  the 
implementation  and  marginally  decreased  the  size  of  the  original  SUN-1  implementation. 

Additional  techniques  could  be  used  for  adaptation  in  fiiturc  implementations  of  the  VGI'S.  For  example, 
if  the  V-System  implemented  virtual  memory  then  the  rarely-used  modules  could  be  page-faulted  into 
physical  memory  only  when  actually  needed.  Dynamic  linking  could  also  be  used  to  reduce  the  minimum 
memory  requirements,  at  the  expense  of  slightly  more  complicated  inter-module  linkages.  Dynamic  linking 
would  also  require  more  complicated  debugging  tools,  and  possibly  introduce  reliability  problems. 


4.2  Screen  Updating 

ITiis  section  discusses  the  techniques  used  for  displaying  objects,  the  end  result  of  VGTS  operations.  In 
contrast  to  many  systems,  tlic  VG  I  S  provides  centralized  rather  than  distributed  control  of  screen  updating. 
'ITie  next  chapter,  and  in  particular  Section  5.4,  will  discuss  die  rationale  behind  tliis  decision  in  greater  detail. 
'I'here  arc  a  fixed  set  of  graphical  primitives,  executed  under  die  control  of  the  VGTS  SDK  interpreter,  display 
manager,  and  drawing  manager,  the  lowest  level  modules  in  Figure  4-1.  This  centralized  control  eliminates 
any  possibility  of  applications  interfering  with  each  other.  In  fact,  operations  on  the  SUN  frame  buffer 
cannot  be  interrupted  and  restarted,  so  some  kind  of  synchronization  is  necessary.  Moreover,  centralized 
control  is  the  only  reasonable  approach  for  distributed  applications.  The  user  methods  of  object  oriented 
window  systems  discus.sed  in  Chapter  2  rely  on  shared  memory,  which  is  not  typically  available  in  a 
distributed  environment. 


4.2.1  Implementing  Overlapping  Viewports 

Originally,  viewports  were  restricted  to  lie  entirely  on  the  screen  and  to  not  overlap.  However,  this  proved 
to  be  inadequate,  since  screen  space  quickly  (illcd  up.  and  viewport  manipulation  commands  often  failed. 
I'hc  current  implementation  uses  a  novel  scheme  of  dividing  each  viewport  into  visible  nt)n-overlapping 
rccUinglos  (called  subxiewports)  whenever  the  screen  laytiut  changes.  The  viewports  are  redrawn  by 
interpreting  the  staictured  display  file  in  each  of  the  subviewporLs.  This  has  the  advantage  of  no  speed 
penalty  for  updating  views  that  are  not  obscured  (the  nonual  case).  Views  which  have  non-rcctangular  visible 
portions  inay  Utke  longer  U)  update  for  complicated  SDl's,  but  almost  always  die  actual  drawing  time  is  tlie 
dominating  factor,  which  is  proportional  to  the  area  being  redrawn  and  independent  of  the  shape  of  tlie 
region.  'Die  resulting  scheme  is  clean  and  simple. 

One  niaior  advantage  over  systems  that  maintain  obscured  bitmaps  (such  as  Apollo  Domain  (8),  Blit 
I  aycis  I  ll).5|.  .md  Spice  Canv.is  (I.IJ)  is  that  no  extra  memory  is  required  to  store  those  obscured  bitmaps.  Ihe 
SDF  can  represent  extremely  large  objects  in  modest  amounts  of  memory.  As  an  example,  consider  the  two 
overlapping  viewports  in  Figure  4-2.  I  he  SDI-  data  structures  take  up  only  a  few  hundred  bytes,  while  the 
bitmap  could  need  many  thousands  of  bytes.  View  number  1  lies  on  top,  and  is  entirely  on  tlic  screen,  so  it 
has  only  one  subviewport,  number  1.  View  number  2  is  partially  obscured,  so  it  has  two  rectangular 
subview  ports,  numbers  2  and  3.  Ihe  "banners”  or  labels  on  the  top  of  each  view  arc  implemented  as 
additional  subviewports,  each  displaying  a  single  item:  a  string  name,  VG  T  number,  optional  view  number 
and  zoom  factor,  and  a  siring  controlled  by  tlic  application. 

Another  adv.mlagc  of  updating  from  tlic  SDF  instead  of  from  a  bitmap,  is  tliat  it  is  often  actually  faster  to 
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Figure  4-2:  Example  of  item  naming 


redraw  the  picture  from  die  Sl)l-'  than  to  restore  the  bitmap,  assuming  that  llic  bottleneck  of  graphics  is  die 
frame  buffer  update  bandwidth.  l-\)r  example,  a  picture  composed  of  vectors  usually  has  a  low  density  of 
pixels  louched  by  die  vectors.  For  scrolling  text,  our  experience  has  been  that  it  is  signincantly  faster  to 
redraw  a  single  character  on  the  SUN-1  than  it  is  to  scroll  it  by  moving  the  biimap.  This  is  because  moving 
the  bitm.ip  touches  c;ich  bit  of  the  fr;ime  bulTer  twice  (one  read  and  one  write),  while  redrawing  louehes  it 
only  once.  The  Sfuirce  for  the  redrawn  character  is  mam  CPU  memory,  which  is  accessed  more  quickly  dian 
frame  biiircr  memory.  Unfortunately,  tlie  SUN-2  frame  buffer  was  designed  to  optimi/c  large  ra.stcr 
operations  used  in  the  raster-oriented  software  marketed  by  SUN  Microsystems,  instead  of  the  many  small 
operations  done  by  the  VG'l'S.  In  other  words,  on  die  SUN-1  frame  buffer  the  bottleneck  was  the  number  of 
bits  per  second  diat  could  be  sent  over  die  I/O  bus,  while  on  the  SUN-2  the  bottleneck  is  the  number  of  raster 
operations  per  second.  The  result  is  that  die  SUN-2  frame  buffer  is  slower  dian  the  SUN-1  for  all  VG'l'S 
drawing  operations. 
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4.2.2  Zooming  and  Expansion 

The  VGTS  provides  support  for  zooming  and  expansion  deptli  that  is  independent  of  its  clients.  Zooming 
consists  of  redrawing  the  SDF  with  larger  objects,  not  replicating  pixels.  Expansion  depth,  one  of  the 
attributes  of  each  view,  indicates  how  far  down  in  die  SDF  to  go  when  displaying  a  symbol.  If  the  expansion 
depth  is  less  than  the  SDF  tree  height,  an  outlined  box  will  be  displayed  at  the  appropriate  point  in  place  of 
the  symbol.  Depending  on  the  size  of  die  box,  die  text  name  of  die  symbol  may  also  be  displayed.  Views  may 
be  zoomed  and  expanded  independently  such  diat  a  user  may  view  an  entire  symbol  in  one  view,  for  example, 
while  simultaneously  viewing  a  piece  of  the  symbol  in  a  zoomed-in  view. 


4.3  Client  Interface 

Hefore  the  techniques  described  in  the  last  section  can  be  used  to  display  objects,  the  objects  must  be 
defined  by  some  client  application  program.  I'he  abstract  objects  and  operations  were  discussed  in  the 
previous  chapter.  Section  3.4.  The  details  of  die  C  language  binding  for  diis  interface  are  discussed  in  the 
V-System  Reference  Manual,  in  the  chapter  on  the  graphics  library  functions  [17].  'fhis  section  discusses 
some  important  design  choices  Uiken  in  die  prototype  VG  I  S  implementation  regarding  the  client  interface. 


4.3.1  Item  Naming 

Items  within  an  SDF  are  named  with  16  bit  identifiers  chosen  by  the  application.  It  is  assumed  that  the 
application  will  maintain  some  higher-level  dati  structures,  along  with  the  appropriate  mapping  to  these 
internal  item  names.  The  item  names  are  global  to  each  SDF',  but  applications  may  also  have  several  SDFs 
for  different  name  spaces.  Item  identifiers  are  referenced  via  a  hash  table,  so  diere  are  no  constraints  on  their 
values  |73|.  Items  that  will  never  be  referenced  can  be  given  item  number  zero,  and  arc  never  introduced  into 
the  hash  table.  In  practice,  only  a  few  ‘‘interesting”  items  are  actually  given  non-zero  numbers.  Item 
numbers  can  refer  to  both  definitions  of  symbols  and  their  instances.  Symbols  are  also  given  string  names, 
but  diese  strings  arc  only  used  for  disambiguation  during  hit  testing,  or  for  displaying  symbols  at  the 
expansion  depdi.  String  names  of  symbols  arc  not  related  to  item  numbers. 

For  example,  a  picture  of  a  bicycle  might  define  a  symbol  for  a  wheel.  I'he  item  number  of  die  top-level 
"hike"  symbol  could  be  1.  with  2  and  3  referring  to  other  parts  of  the  symbol.  The  definition  of  die  wheel 
symbol  is  given  item  number  4.  Tlicrc  may  dicn  be  two  instances  (calls)  of  item  number  4.  which  could  be 
given  item  numbers  5  and  6.  The  individual  spokes  of  die  wheel  arc  components  of  symbol  number  4,  but  arc 
all  given  item  number  0,  since  we  will  never  want  to  refer  to  any  of  them  individually.  If  it  is  desired  to  delete 
or  move  any  individual  spoke,  then  each  of  these  items  may  also  be  given  numbers.  Figure  4-2  on  page  44 
illustrates  diis  example. 

4.3.2  Representing  SDF  Items 

Section  3.4  introduced  some  of  the  kinds  of  item  types  used  in  the  VG  TS.  Hie  implementation  uses  a 
compact  linked  list  of  display  records  to  represent  these  items  internally.  Each  item  within  an  SDF  has  the 
following  parameters: 

Item  A  16  bit  unique  (within  the  SDF)  identifier  for  this  object,  or  zero.  Iliis  identifier  is 
referenced  by  the  client  when  performing  editing  operations. 

Type  One  of  the  predefined  types  described  below;  cither  a  primitive  type  or  one  to  indicate 
structure.  Currently  eight  bits  arc  allocated  to  diis. 
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TypcData  Eight  bits  of  typc-dcpcndcnt  infonnation,  such  as  the  stipple  pattern  index  for  a  filled 
rectangle.  Most  attributes  arc  stored  here,  such  as  the  font  index  for  general  texL 

Xmin  Minimum  X  coordinate  of  the  extent  All  coordinates  are  in  “world”  coordinates,  stored  as 
signed  16  bit  signed  integers. 

Xmax  Maximum  X  coordinate  of  the  extent 

Ymin  Minimum  Y  coordinate  of  tlic  extent 

Ymax  Maximum  Y  coordinate  of  the  extent 

Pointer  Depending  on  the  type,  this  is  either  a  pointer  to  some  data  such  as  an  ASCII  text  string,  or 
for  symbol  calls,  a  pointer  to  the  called  symbol. 

Sibling  All  the  component  items  within  a  symbol  are  linked  together  via  this  chain.  This  is  a 
circular  chain,  as  illustrated  in  Figure  4-2.  Normally  tliis  relationship  should  not  be  visible 
to  the  client  unless  the  client  wants  to  step  through  a  symbol  definition  in  order. 

Some  of  the  meanings  of  the  above  fields  depend  on  the  type  of  the  item.  The  following  are  tlie  types  of 

items  that  occur  in  structured  display  file  records  in  the  prototype  implementation: 

Filled  Rectangle  A  rectangle  filled  with  some  texture.  The  'I'ypeOata  field  specifies  the  stipple  pattern,  or 
color  on  tlic  Iris  system. 

Horizontal  Line  Horizontal  line  from  (Xmin.Ymin)  to  (Xmax.Ymin).  Ymax  is  ignored. 

Vertical  Line  Vertical  line  from  (Xmin.Ymin)  to  (Xmin.  Ymax).  Xmax  is  ignored. 

Point  A  point,  which  usually  appears  as  a  2  by  2  pixel  square  at  (Xmin.Ymin). 

Simple  I'cxt  A  simple  text  string,  with  (Xmin.Ymin)  as  its  lower  left  corner.  This  produces  text  in  a 

single  fixed-width  font  that  can  be  drawn  very  quickly.  The  values  of  Xmax  and  Ymax 
need  not  surround  die  text,  but  they  are  used  as  aids  for  redrawing,  so  should  correspond 
roughly  U)  the  real  extent. 

General  Line  A  generalized  line,  from  (Xmin.Ymin)  to  (Xmax.Ymax).  Note  diat  Xmin  etc.  are  slightly 
misleading  names.  The  SDF  manager  acuially  sorts  die  endpoints  and  calculates  the  extent 
correctly. 

Outline  Outline  for  a  selected  symbol.  Xmin,  Xmax.  Ymin  and  Ymax  give  the  box  for  the  outline. 

I’he  TypcData  field  specifics  bits  to  select  each  of  die  edges:  LcftTxlgc,  RightEdgc, 
TopFxJgc  or  llottomlidgc. 

Text  A  string  of  general  text,  with  a  lower  left  corner  at  (Xmin.Ymin).  The  TypcData  field 

specifics  the  font  number.  Xmax  is  recalculated  from  the  width  information  for  die  font. 

Raster  A  general  raster  bitmap  with  a  lower  left  corner  at  (Xmin.Ymin).  and  upper  right  corner  at 

(Xmax.Ymax).  The  TypcData  field  dclcnnincs  if  the  raster  is  written  with  ones  as  black  or 
white.  The  pointer  field  points  to  the  actual  biunap,  in  16  bit-wide  swaths. 

Spline  A  spline  object,  optionally  filled  with  a  specified  pattern.  ’Hie  pointer  field  points  to  a 

SPTiNn  structure. 

Filled  Polygon  A  list  of  points  which  defines  a  polygon  diat  can  be  optionally  filled  with  a  specified 
pattern. 
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Arcs  A  list  of  points  defining  a  series  of  circular  arcs.  Although  arcs  can  be  very  closely 

approximated  by  splines,  this  provides  a  simpler  interface  and  faster  implementation. 

There  are  a  few  other  types  that  are  not  visible  to  the  user.  For  example,  symbol  definitions  and  calls  are 
represented  as  items  with  most  of  the  same  attributes. 

4.3.3  Interface  to  V-System  Protocols 

The  VG  rs  implements  a  subset  of  the  standard  V  I/O  protocol  [33].  nius  simple  applications  can  write  to 
standard  output  and  read  from  standard  input,  with  no  changes  required  when  executing  under  die  VG'I'S, 
under  die  simple  terminal  server,  or  with  input  or  output  redirected  to  any  other  file.  Pads  are  created  by  the 
standard  request  to  create  a  file  instance,  and  destroyed  by  the  standard  request  to  release  a  file  instance. 

'ITic  VGTS  also  implements  some  of  the  operations  in  the  V  distributed  naming  protocol  [34].  When  the 
standard  directory  listing  program  is  used  to  list  the  directory  of  the  context  named  vgts,  information  about 
the  currently  defined  virtual  terminals  will  be  printed.  Thus  each  virtual  terminal  is  a  named  V  I/O  object 

4.3.4  Binding  the  VGTP  to  a  Byte  Stream 

'llic  fimetions  described  in  section  3.4  arc  all  encapsulated  in  escape  sequences  to  form  a  byte  stream  using 
a  very  simple  protocol.  Each  call  causes  a  special  flag  character  to  be  sent  (the  ASCII  character  called  US,  octal 
037)  followed  by  a  one-byte  code  indicating  the  function  number.  This  is  followed  by  each  of  the  arguments 
to  the  function,  transmitted  with  the  high-order  byte  first  in  each  argument  Any  return  values  arc  sent  with 
the  same  escape  character  followed  by  die  bytes  of  Uic  returned  value,  high-order  byte  first.  Most  parameters 
arc  sixteen  bit  unsigned  integers,  requiring  two  bytes  for  each  value. 

This  results  in  a  very  small  number  of  bytes  for  common  operations.  As  we  shall  sec  in  the  next  chapter, 
this  makes  the  protocol  fairly  insensitive  to  network  speeds.  A  more  ambitious  project  would  have  used  an 
automatic  "remote  procedure  call"  generator  (102),  but  the  manual  method  was  sufficient  for  tliis  project, 
since  the  functional  interface  did  not  change  very  often.  An  automatic  KPC  mechanism  should  not  affect  the 
performance  of  applications,  and  in  fact  should  be  entirely  iransparcnL 

4.3.5  Network  Transport  Protocols 

I'hc  encapsulation  of  the  VGTP  within  transport  protocols  is  illustrated  in  Figure  4-3.  Dtishcd  lines 
separate  library  packages,  solid  lines  separate  programs,  and  arrows  indicate  network  proUx:oIs.  All 
interaction  to  tlie  VG'I'S  is  through  the  V  Input/Output  prot(x:ol  (VIO).  which  provides  a  byte  stream  of  data 
in  terms  of  V  mcssiiges.  Mie  i  n  terp  module  decodes  graphical  operations  out  of  this  byte  stream,  providing 
tlic  server  side  of  the  remote  procedure  call  hieility.  The  terminal  emulator  is  also  provided  as  a  simple  VIO 
byte  stream  interface.  Clients  use  citlicr  the  VIO  stream  package,  or  the  UNIX  Stdio  package.  I’hc  stubs 
module  encodes  graphical  inforniation  on  the  standard  output  channel  and  dectides  responses  from  standard 
input 

For  distributed  applications,  one  of  three  network  transport  protocols  can  be  used*: 

1.  Pup  ITi  Nin  [19] 


■'noth  Ti-i  Niri  protocols  arc  used  as  "iransporl"  by  remote  VGTS  clients,  even  though  they  are  usually  treated  as  presentation-level  in 
the  ISO  hierarchy  Ihc  distinction  Ls  in  name  only. 
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Figure  4-3:  Hncapsulation  of  the  Virtual  Graphics  Terminal  Protocol 

2.  Internet  Titnih' [107] 

3.  V-System  Inter- Kernel  Protocol  [31] 

'Ihesc  arc  standard,  general-purpose  transport  protocols,  with  nothing  specific  in  their  design  fot  distributed 
graphics.  In  particular,  die  Internet  Protocol  allows  use  of  any  of  the  hundreds  of  computing  resources  on  the 
Ari’A  Internet  with  no  modifications  to  their  operating  systems. 


4.4  The  View  Manager  Interface 

The  view  manager  provides  the  visible  interface  between  a  person  using  the  V-System  and  the  VG  TS.  'ITiis 
is  very  difl'crcni  from  tlic  programmer’s  interface  to  the  VG  I  S  which  wasdcscrihcd  abstractly  in  Section  3.4, 
and  discus.scd  in  the  previttus  sation.  Programs  create  SDI-'s  and  objects  within  tlicm,  and  a^sociatc  these 
obJcTts  wiili  Virtual  Graphics  rcrininals(VG  I  s).  Through  die  view  manager,  die  user  maps  these  VG  Tsonto 
a  physical  screen,  and  manipulates  the  resulting  views.  The  view  manager  also  provides  the  ability  to  manage 
executives,  through  an  inlerfaee  to  the  exec  server.  A  similar  componeni  in  ttlher  systems  is  usually  called  die 
window  manager  or  screen  manager.  This  section  describes  the  default  view  manager  in  the  prttloiype  VG'I'S 
impIcmenUition. 


4.4.1  VGTS  Conventions 

On  the  physical  screen,  virtual  terminals  appear  as  white  overlapping  rectangles  with  a  black  border  and  a 
label  near  the  top  edge  called  die  banner.  Ihere  is  at  most  one  virtual  terminal  (usually  a  pad.  or  text-only 
virtual  terminal)  diat  is  receiving  input  from  die  keyboard,  alttng  with  possibly  other  virtual  graphics 
terminals  receiving  graphical  input.  These  input  selections  arc  indicated  by  a  flashing  box  (the  text  cursor)  in 
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the  text  virtual  terminal,  and  a  black  label  on  all  die  views  that  arc  accepting  input.  Note  that  all  virtual 
terminals  arc  always  aclive  in  the  sense  that  any  application  may  run  or  change  die  display  in  any  virtual 
terminal  at  any  time  independent  of  these  selections;  selections  only  apply  to  input 

There  arc  a  few  conventions  for  using  the  mouse  with  the  VG'l'S.  A  click  consists  of  pressing  any  number 
of  buttons  down  and  releasing  them  at  a  certain  point  on  die  screen.  While  the  buttons  arc  down  there  may 
be  some  kind  of  feedback;  usually  an  object  diat  follows  die  cursor.  The  click  is  usually  only  acted  upon 
when  all  die  buttons  arc  released,  so  if  users  decide  they  have  made  a  mistake  after  pressing  the  buttons  they 
can  slide  die  mouse  to  some  harmless  position  before  releasing  the  buttons.  Holding  all  three  buttons  down  is 
also  interpreted  as  a  univcreal  abort  by  most  programs  and  the  view  manager.  I'lic  click  event  is  sent  to  the 
program  asscKiatcd  with  the  view  in  whicli  the  event  occurred  (through  its  VG  T). 

Clicking,  the  left  or  middle  button  of  die  mouse  in  a  non-sclcctcd  virtual  terminal  will  cause  it  to  be  selected 
for  input.  Views  of  selected  pads  will  be  brought  to  the  top.  Ilic  input  pad  can  be  changed  by  typing  the 
control  up-arrow  character  (octal  036)  followed  by  a  single  command  character.  The  only  command 
characters  interpreted  by  the  VG  TS  arc  1-9  to  select  the  given  pad  for  inpuL 

Although  the  user  can  always  create  views,  some  are  created  by  application  programs.  In  particular, 
programs  like  die  text  editor  will  create  a  pad  when  a  new  virtual  text  terminal  (pad)  is  desired.  When  a 
V-System  program  requests  the  creation  of  a  pad,  the  cursor  will  change  to  die  word  “Fad”.  At  this  point,  the 
user  holds  down  any  button,  and  an  outline  of  the  view  that  will  be  created  will  be  tracked  on  the  screen.  The 
user  positions  the  view  where  desired,  and  releases  the  buttons.  Other  prompts  can  appear  as  cursor  changes 
to  denote  that  the  next  click  will  not  be  treated  as  normal  input.  Unfortunately  such  convenience  features 
make  the  view  manager  very  device-dependent 

4.4.2  View  ManagerMenus 

The  view  manager  menus  can  always  be  invoked  by  moving  the  cursor  to  the  grey  background  area  or  any 
virtual  terminal  not  selected  for  input  (except  in  die  banner  area)  and  pressing  the  right  button.  The 
following  commands  arc  available  from  die  view  manager  menus: 

Create  View  Creates  another  view  of  an  existing  VGT.  Move  the  cursor  to  the  desired  position  of  any 
one  of  the  four  corners  for  the  new  viewport  Hold  any  bultoii  down,  and  move  the  cursor 
to  the  diagonally  opposite  corner.  An  outline  of  the  new  view  will  follow  the  cursor  as  it 
moves  with  the  button  down.  Let  die  button  up.  and  then  point  at  the  VG  T  diat  is  desired 
to  be  viewed  with  the  lelt  or  middle  buttons,  or  hit  die  right  button  and  select  die  VGT 
from  the  menu.  Nonnally  this  command  is  only  used  with  graphics  VGTs. 

Delete  View  One  view  is  clicked  and  removed  from  the  screen.  If  the  last  view  of  a  VG  T  is  deleted,  it 
diK's  not  destroy  the  VG  I  or  die  process  as.s«Kiatcd  with  it.  It  is  still  possible  to  create 
views  of  the  VG  I  by  using  the  right  button  menu  in  die  Create  View  command. 

Move  Viewport  Fressing  any  button  selects  a  viewport  to  move.  While  the  button  is  being  held  down,  die 
outline  of  the  vicwpoit  will  move,  following  the  cursor.  I'hc  button  is  released  at  the 
desired  position.  None  of  the  other  view  parameters  arc  changed.  A  shortcut  to  this 
function  is  obtained  by  pres.sing  die  middle  button  while  pointing  to  the  banner  of  the 
desired  viewport.  Ilic  viewport  outline  will  follow  die  cursor  undl  die  middle  button  is 
released. 

Make  Top  llrings  the  view  to  the  top.  potentially  obscuring  other  views.  A  shortcut  to  this  function  is 

obtained  by  pressing  die  left  button  while  pointing  to  die  banner  of  the  desired  viewport 
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Make  Bottom  Pushes  the  view  to  tlic  bottom,  potentially  making  otlicr  views  visible.  A  shortcut  to  this 
function  is  obtained  by  pressing  the  right  button  while  pointing  to  the  banner  of  the  view. 

Exec  Control  Selects  a  submenu  to  create  another  executive,  destroy  an  executive  (and  the  teams  running 
in  it),  kill  a  program,  or  control  paged  output  mode.  When  creating  an  executive,  the 
outline  of  the  new  pad  will  follow  the  cursor  as  the  user  holds  the  button  down.  The  user 
lifts  the  button  up  at  the  desired  position,  or  presses  all  diree  buttons  to  abort.  A  shortcut 
to  the  exec  control  menu  is  obtained  by  pressing  both  tJic  middle  and  right  buttons  while 
the  cursor  points  to  the  gray  background  or  the  display  area  of  a  viewport  not  selected  for 
input 

Graphics  Commands 

Selects  another  menu  of  commands  tliat  arc  usually  only  applied  to  graphics  views.  A 
shortcut  to  this  menu  is  available  by  clicking  tlie  right  and  left  buttons  at  the  same  time 
while  tile  cursor  points  to  the  gray  background  or  the  display  area  of  a  viewport  not 
selected  for  input  'I'hcsc  graphics  commands  are  described  below: 

Center  Window  Click  the  position  to  become  tlic  center  of  the  viewport.  'ITiis  command  d(x:s  not  change 
the  position  of  the  viewport  on  the  screen,  just  the  objects  within  the  view.  Normally  this 
command  is  applied  only  to  graphics  views. 

Move  Edges  Push  any  button  down  next  to  an  edge  or  corner,  move  that  edge  or  corner  to  the  new 
position,  and  let  the  button  up.  The  edge  outline  should  follow  the  cursor  as  long  as  the 
button  is  held  down.  Docs  not  move  the  objects  being  viewed  relative  to  the  screen. 

Move  Edges  +  Object 

Similar  to  the  previous  command,  but  tliis  one  drags  tlic  underlying  objects  around  with 
the  moved  edge  or  corner,  while  the  previous  command  keeps  it  stationary  with  respect  to 
the  screen. 

Zoom  Invokes  a  zewm  mode,  indicated  by  a  change  in  the  cursor  to  the  word  “Zoom”.  Users  can 

get  out  of  this  mode  in  two  different  ways:  First,  clicking  the  left  or  middle  buttons  when 
the  cursor  is  inside  a  view  of  a  pad  returns  from  the  view  manager  and  selects  that  pad  for 
input.  As  a  side  effect  tliat  view  is  also  brought  to  the  top.  Second,  users  can  click  the  right 
mouse  button  to  exit  tliis  mode.  Ilie  cursor  should  change  back  to  the  normal  arrow. 

The  left  and  middle  buttons  in  zoom  mode  zoom  out  and  in  respectively.  'ITiat  is,  the  left 
button  makes  the  objects  look  smaller,  and  the  middle  button  makes  tlicm  look  larger.  A 
shortcut  to  this  mode  is  available  by  clicking  the  middle  and  left  buttons  at  the  same  time 
while  the  cursor  points  to  the  gray  background  or  the  display  area  of  a  viewport  not 
selected  for  input 

Expansion  Depth  Click  to  determine  the  view,  then  select  the  new  expansion  depth  from  the  menu.  Symbols 
will  not  be  expanded  more  than  this  many  levels  inU)  the  hierarchy.  Insicad  they  will  be 
drawn  as  outlines  with  text  for  their  names  if  Uicrc  is  rixim.  The  default  expansion  depth  is 
infinity,  so  all  levels  will  be  normally  expanded. 

Redraw  Redraws  all  the  views  on  the  screen;  necessary  only  during  debugging. 

Toggle  Grid  Click  once  to  turn  the  grid  on  if  it  is  off,  or  off  it  is  on  in  tlie  view  selected.  'ITie  grid  dots 
are  every  16  screen  pixels,  and  always  line  up  with  the  origin. 

Debug  Enables  extra  printouts,  for  maintenance  use  only,  ’lliis  command  asks  for  confirmation, 

to  discourage  its  accidental  invocation. 
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4.5  A  Simple  Application 

The  VG  rs  and  View  Manager  provide  many  ftinctions  that  encourage  applications  to  be  simple  and 
consistent.  The  s  i  1  ed  i  t  program,  a  simple  illustration  editor,  is  an  example  VGTS  client  program.  It  uses  a 
compatible  file  format  with  the  Alto  SIL  program,  although  some  advanced  features  such  as  macros  arc  not 
implemented  [141].  ibe  main  limitation  of  this  format  is  that  only  horizontal  and  vertical  lines  arc  supported, 
with  a  limited  range  of  fonts.  On  the  other  hand,  it  is  simpler  and  faster  than  the  other  V-System  illustrator 
(draw),  and  illustrations  produced  by  s  i  1  edi  t  can  be  easily  printed  or  inserted  into  other  documents.  A 
remote  version  of  this  program  executes  under  Unix,  although  users  prefer  the  V-System  version  when 
permitted  by  workstation  memory  limitations. 


4.5.1  Basic  Operation 

The  s  i  I  ed  i  t  program  is  invoked  witli  one  argument  in  the  V-System  executive: 
si  1  edit  filename,  s^^ 

It  first  attempts  to  open  the  file  name  given  as  an  argument.  If  no  such  file  exists,  die  program  creates  one.  A 
graphics  VG  T  is  created,  and  the  cursor  changes  to  the  “View"  prompt  indicating  tlic  creation  of  a  default 
view.  The  default  view  will  be  slightly  larger  than  the  illustration,  or  a  whole  page  if  tlic  illustration  is  empty. 
The  user  presses  and  holds  any  button  causing  an  outline  of  the  new  view  to  appear  and  track  the  cursor.  The 
user  moves  the  upper  left  corner  of  the  default  view,  and  lifts  the  button  up  when  the  view  is  positioned. 
Next  the  si  1  edit  program  prints  the  niuncs  of  the  text  fonts  to  be  used,  and  tries  to  load  them  into  the 
VGTS.  flic  existing  illustration  is  displayed  (along  with  some  performance  statistics),  and  the  following 
prompt  appears: 

Use  mouse  buttons;  Mark,  Select.  Menu 

'Ibis  means  two  mouse  buttons  arc  used  for  the  basic  commands,  with  other  commands  available  through 
combinations  of  buttons  or  from  the  command  menu. 

Ibc  mirk,  indicated  by  an  “X”  shaped  cross,  is  one  end  of  lines  and  the  position  of  added  text.  Once  added 
to  the  illustration,  objects  can  be  modified  by  selecting  them  and  performing  a  modification  command. 
Selected  objects  appear  highlighted  in  some  way,  altliough  the  exact  fonn  of  tlic  highlight  may  depend  on  the 
VG  I  S  implementation.  In  the  SUN  implementation,  objects  arc  normally  black  on  white,  with  selected  lines 
half-tone  gray  and  selected  text  appearing  within  a  gray  box. 


4.5.2  Commands 

Commands  available  on  the  mouse  arc  as  follows: 

Left  Dutton  Moves  the  mark  to  the  point  of  tlic  click.  Ibc  “X"  shaped  cross  moves  to  the  new  location. 
The  mark  is  normally  moved  before  drawing  lines  or  placing  text. 

Middle  Hutton  Selects  the  single  objat  at  or  near  tlic  click.  Any  other  tibjals  previously  selcTted  arc  no 
longer  selected.  The  program  will  echo  Uic  kind  of  object  selected,  or  issue  a  diagnostic  if 
no  objects  arc  found. 

I, eft -(-Middle  Draws  a  line  from  the  mark  to  the  point  of  the  click,  of  current  line  width.  'Ibc  line  is 

citlicr  horizonUil  or  vertical,  depending  on  which  difference  in  position  is  larger.  This  is  a 
faster  way  of  drawing  lines  than  using  tlic  menu.  Ibc  mark  is  moved  to  the  point  of  the 
click,  to  facilitate  drawing  a  scries  of  connected  line  segments. 

Middle -(- Right  Adds  tlic  object  near  tlic  click  to  tlic  selection.  Ibis  is  in  contrast  to  the  Middle  Hutton, 
which  causes  exactly  one  object  to  be  selected.  Use  this  command  to  select  several  objects. 
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Riglu  Button  Pops  up  a  command  menu,  as  described  below. 

More  advanced  commands  are  available  on  the  menu  as  follows: 

Quit  Exits  without  saving  the  illustration.  Usually  the  Write  command  should  be  used  to  save  the 

flic,  so  if  there  have  been  changes  since  the  last  Write  command,  confirmation  is  requested. 

l.inc  Width  Pops  up  a  menu  of  default  line  widths.  Select  the  desired  new  width  from  1  to  8  units.  Clicking 
outside  tlic  menu  results  in  no  change. 

Delete  'ITic  selected  objects  arc  deleted. 

Unsclcct  A  click  is  requested;  the  object  near  that  click  will  no  longer  be  selected. 

Draw  Line  A  click  is  requested,  and  a  horizontal  or  vertical  line  is  drawn  between  the  mark  and  the 
position  of  the  click. 

Add  Text  A  line  of  text  is  requested,  and  the  text  is  added  at  the  position  of  the  mark  in  the  current  font 

Modify  Text  Selects  another  menu  for  commands  used  to  modifying  text 

Write  Writes  tlic  illustration  back  to  the  file  given  on  the  command  line. 

Stretch  Line  Position  the  cursor  near  one  end  of  the  selected  line,  and  hold  down  a  button.  ITie  end  of  the 
line  will  move  following  the  cursor  until  the  button  is  released.  (Available  only  in  the  native 
V-System  version.) 

Move  Position  the  cursor  anywhere  in  any  view  of  the  illustration  and  press  any  button.  The  selected 
objects  will  follow  the  cursor  until  tlic  button  is  released.  (Available  only  in  tlic  native  V- 
System  version.) 

Copy  Position  the  cursor  anywhere  in  any  view  of  the  illustration  and  press  any  button.  A  copy  of  the 

selected  objects  will  follow  the  cursor  until  the  button  is  released.  (Available  only  in  the  native 
V-System  version). 

Box  Move  tlic  cursor  to  one  corner  of  the  box.  and  press  any  button.  While  holding  down  the 

billion,  position  tlic  opposite  corner  of  tlic  box.  ’Ilic  box  will  be  drawn  in  tlic  current  line 
width,  riic  box  can  be  aborted  by  prcs.sing  all  three  buttons  at  tlic  same  time.  (Available  only 
in  the  native  V-System  version.) 

Select  Area  Move  the  cursor  to  one  corner  of  tlic  area,  and  press  any  button.  While  holding  down  the 
billion,  position  the  opposite  corner  of  the  area.  All  objects  within  the  area  will  be  selected. 
(Available  only  in  the  native  V-System  version.) 

Debug  E.nalilcs  several  debugging  print  statements,  for  maintenance  use  only.  (Available  only  in  UNIX 
version.) 

The  following  commands  are  used  to  modify  text: 

Edit  Text  Ilic  selected  text  is  stuffed  inio  the  VG  I’S  line  buffer,  and  edited  by  the  user. 

Default  Font  Displays  a  menu  of  fonts  to  become  the  new  default  font,  for  Text  added  with  tlic  Add  Text 
command. 

Change  Font  Displays  a  menu  of  fonts  to  be  the  new  font  for  the  selected  text 
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4.5.3  Selecting  Alternate  Fonts 

Two  text  font/sizc  combinations  are  available  in  SlI.  format,  with  regular,  bold  and  italic  faces  in  each 
fonl/sizc  combination.  Default  fonts  arc  Helvetica?  and  HclvcticalO,  with  HelvcticaTB,  the  bold  face, 
Helvetica?!  tlic  italic  face,  etc.  A  third  font,  1  cmplate64,  is  used  to  draw  circles  and  diagonal  lines. 

Other  fonts  can  replace  Helvetica  by  creating  a  file  with  the  name  filename,  fonts.  This  file  contains  the 
names  of  the  fonts  to  be  used,  one  per  line.  Comments  arc  indicated  by  a  #  character  at  the  start  of  a  line. 
The  default  fonts  arc  acceptable  for  illustrations  to  be  included  in  papers,  but  for  slides  larger  fonts  like  12 
and  18  point  should  be  used.  Thus,  for  example,  the  font  File: 

#  font  file  for  si  ides 
He! vetical2 
Hel veticaia 

could  be  used  when  making  slides.  A  simple  command  to  list  the  defined  global  symbols  in  the  font  library 
can  be  used  to  determine  what  fonts  arc  available. 


4.5.4  Generating  and  Previewing  Printed  Copy 

A  related  program  called  s  i  1  pres s  produces  printed  illustrations  from  SIL  format  files.  Alternate  fonts 
can  be  selected  as  in  die  s  i  1  ed  i  t  program.  The  command  line: 
silpress  filename. sil 

converts  the  named  illustration  into  a  printing  format  file  and  queues  it  for  the  local  laser  printer.  An  option 
is  available  to  retain  the  printer  format  file,  to  merge  the  illustration  into  a  dcxrumcnt  produced  with  the 
Scribe  or  'l'|.X  document  compilers.  It  may  take  several  iterations  to  get  proper  positioning  and  size,  but  it  is 
faster  titan  using  a  scissors  and  paste.  The  show  program  can  be  used  to  preview  documents  including 
illustrations  before  they  arc  printed. 

4.6  Summary  of  Implementation  Status 

Virtual  Graphics  Terminal  Servers  have  been  implemented  for  five  varieties  of  SUN  workstation,  with  two 
kinds  of  frame  bulTci's.  Interface  libraries  have  been  written  in  C  and  Intcrlisp.  The  C  interface  for  Unix  is 
callable  from  other  languages  such  as  Pascal.  Implementations  for  Utc  iKis  worksUition  and  VAXSUition  arc  in 
progress  at  the  time  of  tliis  writing. 

Current  applications  include: 

•  Hmacs  and  an  Kmacs-like  text  editor  [21], 

•  a  VLSI  layout  editor  [42], 

•  a  font  design  system  [74], 

•  a  font  and  bitmap  editor, 

•  two  document  illustrators, 

•  a  document  previewer, 

•  some  distributed  games,  and 

•  a  variety  of  display  tools  for  vector  graphics  and  raster  images. 

All  applications  may  be  am  directly  on  workstations  if  they  have  enough  memory.  Many  may  also  be 
available  remotely,  under  systems  supporting  appropriate  network  protocols  and  interface  libraries,  such  as 
Vax/Unix  or  1)1  c  Systcm-20/ 101^-20.  Since  all  interaction  goes  tlirough  die  VG  I’S,  other  clients  include 
executives  and  any  remote  applications  accessible  via  IT;i.Ni:i -style  protwols.  nuts,  we  have  implemented 
clients  of  types  A  through  D  in  L'igure  3-5.  With  respext  to  short-circuiting,  tlic  VG  TS  handles  cursor  control, 
hit  detection,  zooming,  line-editing,  and  all  screen  management  Functions. 
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The  implementation  is  reliable  and  fast  enough  to  be  used  as  a  general  computing  environment.  In  fact, 
this  thesis  was  written  primarily  using  a  text  editor  under  the  VG  TS,  and  all  diagrams  were  produced  using 
the  illustration  editor  described  in  the  previous  section.  The  experience  gained  from  this  use  helped  to  judge 
the  importance  of  criteria  such  as  performance  and  reliability. 

Appendix  C  gives  some  details  of  the  development  of  the  VGTS.  including  other  people  who  contributed 
software  to  the  effort  The  prototype  implementation  took  less  than  one  year  by  tlic  author,  with  slow 
evolution  continuing  by  others,  llie  next  year  was  spent  evaluating  the  design,  which  is  discussed  in  the  next 
chapter,  and  taking  measurements,  which  will  be  discussed  in  Chapter  6. 
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VGTS  Design  Rationale 

ITic  partitioning  problem  is  flill  of  trade-offs:  most  design  choices  have  both  advantages  and  disadvantages. 
Some  of  these  trade-offs  are  discussed  in  this  chapter,  along  with  rationale  for  the  way  decisions  were  made  in 
the  VG  rS.  One  of  the  basic  trade-offs  is  that  for  every  "feature”  to  be  added  there  is  an  associated  cost.  The 
cost  must  be  balanced  carefully  against  the  potential  benefit  of  the  feature.  Since  this  was  a  research  project, 
we  were  concerned  with  developing  the  minimum  functionality  to  create  a  tool  for  some  prototype 
applications  and  taking  measurements,  rather  than  a  system  that  could  meet  everyone’s  needs. 

Many  of  the  factors  internet  with  each  other.  For  example,  the  general  partitioning  issues  discussed  in  the 
first  section  could  cause  performance  problems  discussed  in  die  second  section,  and  analyzed  in  the  third 
section.  The  results  of  this  analysis  lead  to  the  centraliziition  decision  given  in  the  fourth  section.  Altliough 
centralization  aids  in  portability  and  uniformity,  it  can  cause  problems  with  customizability.  In  the  last 
section,  the  suiUibility  of  tlic  VGTS  design  for  the  future  is  discussed. 


5.1  General  Protocol  Issues 

Some  basic  problems  appeared  when  trying  to  define  a  good  interface  (VGTF)  to  the  VGTS.  Although 
total  application  and  device  independence  is  a  laudable  goal,  it  can  lead  to  a  VGTS  that  supports  too  much 
fiinction  for  some  applications  and  too  little  function  for  others.  Both  situations  lead  to  excessive  overhead: 
the  first  because  the  VGTS  is  doing  too  much;  the  second  because  the  application  must  go  to  extra  lengths  to 
subvert  the  VGTS.  For  example,  if  the  VGTS  were  tailored  for  the  basic  SUN  workstation,  it  would  include  a 
variety  of  routines  for  clipping  and  scaling.  However,  in  the  IRIS  workstation  these  ftinctions  are  provided  in 
hardware  by  the  Geometry  Kngihe(38l.  General'y.  the  iRls  provides  considerably  more  functions  tlian  the 
Sun  worksuition.  favoring  additions  to  the  VG'IP.  Thus,  the  VG  I  S  itself  had  to  be  structured  as  a  collection 
of  building  blocks,  and  careful  consideration  was  given  to  the  intended  range  of  graphics  devices  and 
applications. 


5.1.1  Fundamental  Implications  of  Partitioning 

Although  networks  should  be  as  transparent  as  possible,  physical  distribution  raises  fundamental  problems. 
In  all  cases  we  would  like  to  limit  both  the  frequency  of  coimminication  and  tlic  amount  of  data  transmitted  at 
any  one  time.  In  some  extreme  cases  this  might  require  caching  mechanisms  on  die  workstation  and 
necessitate  complicated  protocols  to  keep  the  workstation  cache  synchronized  with  tlic  remote  database. 

Nevertheless,  we  observed  tliat  most  interactive  programs  could  be  divided  into  a  froiiieiul  lliat  converses 
with  the  user  and  a  /wcAc/x/ that  does  ihc  real  processing.  Ihis  simple  model  of  user  interaction  is  illustrated 
in  l  igurc  5-1.  Hie  ide.il  VG  I  S  would  provide  a  common  user  inlerraee  portion  and  avoid  the  duplication 
and  inconsistent  interfaces  tliat  currently  abound  between  applications.  In  so  doing,  it  would  slitirl  ciraiil  the 
traditional  interactive  response  cycle  between  tlic  user  and  tlic  application  [55). 
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orcuH  Database 

Figure  5- 1 ;  User  interactive  response  cycle 

Short-circuiting  is  possible  at  a  number  of  different  levels,  including: 

•  mouse-controlled  cursor:  The  updating  of  the  cursor  position  is  performed  by  the  VG'l'S  in 
response  to  user  motion  of  the  mouse  (or  similar  pointing  device). 

•  screen  management  functions:  These  arc  necessary  to  allow  multiple  applications  to  run 
concurrently  without  interference. 

•  hit  detection:  Applications  arc  informed  when  a  significant  event  occurs,  such  as  selection  of  an 
object;  they  do  not  keep  track  of  the  cursor  position. 

•  editing:  'fhe  VGTS  supports  editing  so  only  some  high-level  indication  of  the  editing  changes 
needs  to  be  communicated  to  the  application. 

Higher-level  short-circuiting,  such  as  local  hit-detection,  provides: 

1.  better  response  for  those  operations  that  can  be  short-circuited. 

2.  better  uiili/Tition  of  powerful  workstation  resources, 

3.  lower  demands  on  the  network  (for  distributed  applications), 

4.  reduced  programming  required  for  applications,  and 

5.  lower  processing  demands  for  hosts. 

However,  to  support  high-level  short-circuiting,  tlic  VGTS  needs  to  be  provided  with  high-level  information 
about  input  and  display  semantics.  That  is.  tlic  VGTP  must  allow  tlic  application  to  communicate  the  model 
that  it  is  representing  pictorialiy,  not  just  the  image  of  that  model,  as  is  common  in  contemporary  graphics 
systems. 

Im.ngine.  for  example,  that  multiple  VGTs  were  mapped  to  overlapping  viewports  on  the  display  screen.  If 
the  top  VG  r  is  repositioned  on  the  screen,  it  and  the  previously  obscured  VG  r(s)  must  be  redrawn.  If  the 
VG  I  S  diKJS  not  have  a  model  of  the  picture  associated  with  tlic  VC  T.  the  VG  I  S  cannot  redraw  the  picture  in 
its  new  position.  Similar  ohscrvalions  hold  for  panning  and  miming.  Instead,  tlic  VG  TS  would  query  a 
possibly  remote  application  to  redraw  the  picture,  a  potentially  limc-consuniing  operation.  Naturally,  it  is 
even  more  important  for  the  VG  I  S  to  support  a  model  if  it  is  to  provide  generic  editing. 

The  exact  kind  of  model  provided  by  die  VG'l'S  could  have  ranged  from  simple  to  complex.  For  example, 
even  systems  like  GKS  provide  a  rudimentary  form  of  modeling  tlirougli  the  Workstation  Independent 
Segment  Storage  capability.  I'hc  power  of  using  more  general  structure  to  define  pictures  has  been  exploited 
since  the  pioneering  SKiriCtit’Ati  system  in  tlic  early  1960s  |135).  Ironically,  a  number  of  early  graphics 
systems  took  tliis  approach  to  its  extreme  by  merging  tlic  application  model  and  tlie  display  file  into  a  single 
graphical  data  base  (36,  112].  Ihis  approach  fell  into  disfavor  largely  because  it  imposed  a  fixed 
representation  on  all  applications.  In  light  of  distributed  graphics,  it  is  also  impractical  to  support  a  single 
data  stnicturc  spanning  multiple  m.ichincs. 
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A  number  of  subsequent  systems  developed  the  notion  of  a  structured  display  file  that  encodes  the 
hierarchical  structure  of  figures,  but  leaves  most  of  the  application-specific  information  in  a  separate 
application  model  [51.  52, 126, 148].  The  structured  display  file  is  partially  redundant,  but  provides  a 
reasonable  amount  of  structure  for  high-level  short-circuiting.  In  particular,  compared  to  the  more 
conventional  segmented  display  file,  a  structured  display  file  can  provide  better  response  when  editing 
objects.  Our  initial  application  was  VLSI  circuit  layouL  which  often  requires  drawing  objects  that  arc  highly 
structured  and  regular  [83]. 

The  use  of  structured  display  files  in  the  VGTS  was  motivated  primarily  by  Sproull  and  Thomas’s 
Stnictured  Format  Protocol,  which  in  turn  was  motivated  primarily  by  network  issues  of  the  sort  discussed  in 
this  section  [126],  However,  that  protocol  was  never  fully  implemented,  primarily  due  to  the  lack  of  sufficient 
computing  power  in  the  terminals  available  at  that  time. 

In  contrast,  more  traditional  graphics  packages  do  not  retain  object  definitions  at  as  high  a  level.  This  has 
three  major  performance  problems  compared  to  the  VG'I'S.  Fii'St,  defining  complex  objects  can  require 
significantly  more  time,  if  those  objects  contain  several  instances  of  the  same  symbol.  Second,  editing  existing 
objects  is  more  time-consuming  since  the  entire  object  must  be  redefined.  Third,  generating  different  views 
of  objects  is  considerably  slower,  since  the  application  itself  must  redraw  each  view.  On  the  other  hand,  “on 
the  fly"  graphics  could  be  faster  under  traditional  systems  since  tlie  VGTS  docs  not  permit  an  application  to 
simply  “write”  on  the  display,  but  rather  requires  the  application  to  repeatedly  edit  and  redisplay  an  entire 
symbol. 

The  evolution  of  graphics  protocols  can  be  compared  to  the  evolution  of  general  purpose  programming 
languages.  The  simple  biunap  oriented  systems  can  be  compared  to  assembly  language,  with  total  generality 
but  lack  of  structure.  The  next  step  is  procedure  abstraction,  which  corresponds  to  languages  like  BCPL  with 
control  sinicturc.  'I'hc  final  step  is  to  provide  both  control  and  data  structure  abstractions,  such  as  languages 
like  Pascal  and  Ada. 

Another  worthwhile  analogy  is  with  low-level  disk  storage  systems.  Farly  attempts  forced  users  to  deal 
directly  with  the  sector,  track,  and  head  allcKation  of  disk  files.  I'hc  concept  of  “logical  blocks"  divides  the 
disk  into  uniformly  sized  and  sequentially  numbered  bUx:ks.  interacting  with  disks  in  terms  of  these  slightly 
higher-level  objects  makes  impossible  some  of  tlie  clever  optimizations  done  by  early  programmers. 
However,  tlie  advantages  of  tliis  level  make  it  almost  universally  used  in  modern  operating  systems. 


5.1.2  Replication  Issues 

The  replication  of  daUi  (keeping  multiple  copies)  tliat  results  from  the  partitioning  described  in  the  last 
section  was  another  major  design  issue  for  the  VG'I'S.  In  graphics  systems,  the  multiple  copies  arc  usually  at 
different  levels  of  representation,  and  the  reason  for  the  copies  is  performance.  I'hc  actual  number  of 
representations  may  vary,  but  most  high-performance  graphics  systems  maintain  some  kind  of  display  list  or 
display  file,  which  is  intermediate  in  representation  between  the  application's  data  structures  and  the  final 
displ.iyetl  picture  [56]. 

For  example,  an  application  usually  reads  some  permanent  data  files  and  constructs  an  internal  model  of 
the  objects  being  displayed.  A  structured  display  file  contains  information  on  structure  and  geometry,  but  no 
application  information.  The  viewing  process  tlicn  displays  this  SDF  with  some  viewing  parameters,  in  our 
ease  on  a  bit  map  terminal.  Unis,  a  typical  situation  may  result  in  four  levels  of  partially  redundant 
information.  I  his  lo.ids  to  several  natural  places  to  partition  tlic  daUi  in  a  distributed  graphics  system,  as 
illustrated  in  Figure  5-2. 

In  each  ease  the  data  structures  below  the  thick  line  arc  stored  on  the  workstation,  and  tliosc  above  the  line 
are  stored  on  some  remote  server  machine.  In  traditional  pcrsmial  computers,  everything  would  be  on  the 
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Figure  5-2:  Possible  data  partitioning  points 

workstation,  witli  the  possible  exception  of  data  on  a  large  archival  file  server  to  back  up  the  personal 
computer’s  files.  For  large  but  diskless  worksuitions.  U  e  application  program  can  still  run  on  the  workstation, 
but  access  the  data  files  over  a  network.  For  smaller  workstations,  the  structured  display  file  is  stored  locally, 
but  the  application  program  runs  on  the  machine  with  the  file  system.  In  the  simplest  of  workstations,  only 
the  bit  map  is  stored  locally. 

Note  that  arrows  only  go  one  direction,  from  the  higher  level  representation  to  the  lower  level  one.  Each 
representation  can  be  generated  from  the  next  higher  layer,  which  greatly  simplifies  the  propagation  of 
updates.  Pipelining,  including  possible  hardware  implementations,  is  much  easier  if  the  conversion  is  always 
in  one  direction.  In  actual  practice,  however,  some  amount  of  short  circuiting  can  be  done  to  pn>vidc  faster 
feedback,  si  ce  input  has  to  travel  in  the  reverse  direction.  Ihe  architecture  and  implementations  of  the 
VGTS  keep  this  short  circuiting  to  a  minimum,  with  only  a  few  simple  local  functions  vastly  improving 
average  performance.  More  research  can  be  done  in  the  future  within  this  framework  on  even  higher  levels  of 
short  circuiting. 

The  V-Sysicm  allows  all  configurations  of  Figure  5-2,  although  the  first  (personal  computer)  and  last  (bit 
map  terminal)  have  been  thoroughly  investigated  in  other  work  discussed  in  Chapter  1.  The  configurations 
labeled  "small  workstation"  and  “large  workstation”  are  the  fix'us  of  lliis  work. 


5.1 .3  Caching  Issues 

One  way  to  further  reduce  communications  costs  would  be  to  write  an  agent  for  each  application  that 
maintains  a  cache  of  the  main  dahi  base.  Once  a  cache  is  in  place,  tlie  usual  problems  of  update  arise.  When 
should  the  cache  updated  and  how  much  of  it  is  updated  at  a  time?  For  example,  there  are  two  interesting 
cases  in  circuit  layout: 


•  When  viewing  the  entire  design  it  is  unncces.sary  to  mainbiin  the  details  of  the  lowest  levels.  'Hiis 
information  may  be  omitted  in  order  to  maintain  the  representation  for  the  higher-level  structure. 
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•  When  viewing  a  specific  component  it  is  unnecessary  to  maintain  the  representation  of  pieces  of 
the  picture  not  now  on  view. 

Thus  the  agent  would  be  constructed  in  such  a  way  so  as  to  maintain  only  the  necessary  data.  Appropriate 
parts  of  the  figure  representation  would  contain  the  equivalent  of  invalid  pages,  leading  to  tlie  equivalent  of 
page  faults. 

The  ideal  VG  TS  would  provide  most  of  this  support  without  requiring  that  a  special-purpose  agent  be 
written  for  each  application.  Although  the  current  VGTS  architecture  allows  caching,  tlic  current  prototype 
docs  not  implement  any.  ITie  si/c  of  most  SDFs  rarely  exceeds  two  or  three  thousand  bytes,  which  is  an 
insignificant  amount  of  memory  compared  to  the  si/c  of  tlic  VG  TS  itself.  This  and  other  possible  VG'I'S 
extensions  arc  discussed  in  the  final  chapter. 


5.1 .4  Transport  Protocol  Issues 

Once  the  higher-level  protocols  arc  decided  upon,  the  transport  and  lower  level  protocols  must  be 
determined.  Possible  choices  for  transport  protocol  include  datagrams,  byte  streams,  and  packet  (or  message) 
streams.  Streams  arc  an  obvious  choice  because  they  generally  provide  a  high  degree  of  reliability,  can  be 
used  with  a  wide  variety  of  terminals  and  networks,  and  simplify  programming  the  applications  and  the 
service.  In  addition,  if  the  workstation  and  remote  host  interact  frequently  or  in  volume,  high  bandwidth  is 
required,  better  achieved  with  virtual  circuits. 

If  bandwidth  requirements  are  low,  then  the  low  delay  of  datagrams  might  be  more  appropriate. 
Furtlicrmorc,  interactive  graphics  requires  real-time  communication,  which  places  greatest  importance  on  the 
most  recent  data.  In  contrasL  streams  under  load  tend  to  lose  or  delay  new  data  in  favor  of  old  data.  Ilic 
graphical  representation  also  impacted  our  choice.  Since  high-level  information  was  being  transmitted,  the 
loss  of  a  single  datagram  would  be  catastrophic.  Thus,  only  “reliable”  stream-oriented  protocols  were  used. 

Fortunately,  the  V-System  architecture  allowed  us  to  experiment  with  several  of  these  protocols.  F!ach 
remote  application  must  have  an  agent  on  tlic  workstation,  so  the  application  and  the  agent  may  communicate 
with  whatever  proUKol  tJicy  desire.  Since  our  prototype  applications  had  relatively  modest  requirements, 
simple  encapsulations  of  tlic  VGTP  with  standard  byte-stream  protocols  were  most  widely  used. 

5.2  Performance  Issues 

Besides  communication  issues,  pcrfonnancc  was  also  kept  in  mind  during  every  phase  of  the  design  of  the 
VG  I  S.  Without  careful  attention,  many  distributed  systems  can  end  up  being  slower  than  tlicir  centralized 
counterparts.  In  particular,  many  previous  distributed  systems  have  failed  because  of  lack  of  attention  to  total 
system  performance.  On  the  other  hand,  although  pinir  performance  guarantees  lliat  a  system  will  fail,  high 
performance  docs  not  guarantee  success.  Other  factors  such  as  tlic  various  costs  associated  with  high 
performance  cannot  be  neglected. 


5.2.1  Code  and  Data  Size 

Despite  the  falling  cost  of  memory,  main  memory  can  still  be  a  major  cost  of  a  computing  system.  In  fact, 
no  matter  how  much  memory  a  computer  system  has,  it  seems  to  almost  always  need  more.  Hliminating 
duplication  is  one  way  to  save  memory,  but  often  redundancy  buys  pcrfonnancc.  A  hardware  cache  is  an 
example  of  such  redundancy  used  to  speed  up  a  physical  pnx:cssor.  Similar  techniques  to  bike  advantage  of 
redundancy  were  used  in  software,  as  discus.sed  in  Section  5.1.2. 


60 


PARirriONING  OF  FUNCTION  IN  A  DISTRIIIUTI-D  GRAPH  ICS  SYSTEM 


Another  way  to  save  memory  is  economy  of  fimction;  to  not  implement  features  tliat  arc  rarely  used,  or 
that  can  be  done  with  existing  capabilities,  unless  they  arc  necessary,  b'or  example,  some  users  might  like  to 
have  blinking  as  a  primitive  attribute.  Since  blinking  can  be  simulated  by  having  the  application  program 
repeatedly  add  and  delete  an  item  from  a  symbol,  blinking  attributes  were  not  included  in  the  VGTS.  'Fhis 
means  tliat  each  application  program  must  include  code  for  blinking  if  desired,  but  the  overhead  is  rarely 
encountered.  On  tlie  other  hand,  diagnostics  and  error  recovery  arc  intended  to  be  rarely  used  in  properly 
written  software,  but  many  understandable  error  mes.sagcs  are  included  in  the  standard  VC  TS,  since  when 
they  are  used  they  can  provide  invaluable  information. 


5.2.2  Resource  Limitations 

llic  concern  for  memory  costs  is  another  prime  motivation  for  the  use  of  high-level  display  files  instead  of 
the  more  common  bitmap  approach.  Note  that  the  architecture  docs  not  explicitly  prohibit  the  storing  of 
bitmaps,  and  in  fact  a  biunap  item  type  is  supported.  However,  Section  4.2.1  described  how  the  prototype 
implementations  redraw  only  from  the  SDF,  with  no  bitmap  caching  of  overlapping  areas  necessary.  The 
current  architecture  requires  that  to  display  large  images  the  entire  bitmap  must  be  transferred  into  tlie  VG'FS 
for  every  change.  This  has  proved  adequate  for  simple  image  display  tasks,  or  editing  small  bitmaps  such  as 
characters.  For  more  intensive  image  processing  applications,  simple  raster  operations  could  be  provided  on 
raster  objects  to  improve  performance  if  necessary. 

Some  display  file  approaches  may  severely  limit  the  maximum  size  or  complexity  of  objects  that  can  be 
displayed.  For  example,  many  traditional  graphics  system  support  only  one  level  of  structure,  the  segment 
Since  we  are  primarily  concerned  with  the  research  community,  absolute  limitations  should  be  avoided 
whenever  possible.  However,  making  some  assumptions  about  maximum  resource  limitations  may  simplify 
the  design  or  improve  performance.  For  example,  a  reasonable  limit  on  the  number  of  virtual  terminals  or 
views  might  be  an  acceptable  limitation,  so  such  limitations  were  included  in  the  prototype  VGTS 
implementation. 


5.2.3  Speed  of  Execution 

'Hie  two  main  measures  of  execution  speed  of  interactive  systems  are  response  time  and  throughput 
Response  time  is  more  important  when  the  user  has  to  wait  Many  users  of  early  workstation  systems  had  to 
spend  much  of  tlicir  time  waiting  while  an  “hourglass”  cureor  appeared  on  the  screen.  Operations  which  take 
significant  amounts  of  time  should  have  been  done  in  the  “background”.  Ibis  requires  a  priority-based 
multi-process  operating  system,  such  as  the  V-System. 

F’or  all  other  applications  for  which  the  user  does  not  have  to  wait  throughput  should  be  maximized.  Since 
the  hardware  trends  are  to  more  specialized  proccs.sors,  a  natural  division  is  suggested  between  prcKesses 
optimized  for  response  time  (interactive)  and  those  optimized  for  throughput  (batch).  A  fairly  common 
scenario  for  users  of  the  VG  I  S  is  to  be  running  an  editor  on  tlie  workstation  in  one  VG  T  while  monitoring 
several  long-running  hatch  operations  in  other  VGTsat  the  same  time. 

5.3  Some  Simple  Models 

As  discussed  in  the  previous  section,  many  attempts  at  distributed  systems  have  failed  due  to  poor 
performance.  In  addition  to  the  inherent  cost  of  the  computation,  the  costs  of  comnumication  between  the 
parts  of  the  distributed  program  are  incurred.  Ibus  the  total  compuUition  cost  of  a  distributed  program  is 
almost  always  higher  tlian  the  total  computation  cost  of  an  equivalent  centralized  program. 
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'Ilicrc  arc  two  approaches  to  improving  the  perfonnance  of  distributed  programs,  both  by  identifying  and 
overcoming  these  communication  costs.  The  traditional  approach  is  to  improve  the  performance  of  the 
underlying  network  communication  mechanism.  The  work  of  Spcctor  and  others  on  remote  memory 
references  is  in  this  category  [125].  A  more  promising  approach  taken  in  the  VGTS  was  to  decrease  the 
amount  of  network  traffic  by  using  higher-level  proUKols.  In  other  words,  reduce  the  frequency  and  volume 
of  communication  by  making  the  applications  more  loosely  coupled. 

For  comparison,  consider  tlie  many  performance  studies  made  of  demand-paged  virtual  memory  systems. 
Although  performance  can  be  improved  by  speeding  up  the  handling  of  page  faults,  better  results  are  usually 
achieved  by  reducing  tlic  number  of  page  faults.  For  example,  increasing  physical  memory,  tuning  the  page 
size,  improving  tlic  locality  of  the  application,  or  using  a  better  selection  algorithm  can  make  as  substantial  a 
difference  as  the  speed  of  the  disk. 

Although  tills  section  docs  not  attempt  an  exhaustive  analysis  of  the  VG'I'S  architecture,  some  very  simple 
models  can  be  developed.  As  in  other  simplified  models  of  two-processor  systems  [132],  a  simple  model  is 
necessary  before  a  more  detailed  one.  Although  some  attempts  have  been  made  to  model  larger  systems  of 
many  processors  [131],  tlicsc  have  mostly  been  theoretical  models  with  very  little  total  system  performance 
data.  At  first  glance  one  might  assume  tliat  tlic  factor  most  important  at  any  given  time  is  the  bottleneck,  and 
construct  a  queuing  theory  model.  'Ilic  problem  is  that  in  a  complete  system  the  bottleneck  is  not  so 
well-defined. 


5.3.1  Comparison  to  Cache  Model 

A  cachs  is  a  well-known  hardware  mechanism  to  improve  performance  of  a  hardware  design  by  taking 
advantage  of  locality  properties  of  software  [121].  'flic  locality  principle  states  that  a  program’s  references  to 
daui  arc  not  uniformly  distributed,  but  instead  concentrate  around  a  set  of  locations  at  any  given 
moment  [108].  A  small  number  of  addresses  arc  responsible  for  a  large  fraction  of  tlic  memory  references. 
ITic  virtual  memory  concept  is  made  possible  by  taking  advantage  of  the  principle  of  locality  at  the  next 
higher  level  in  the  storage  hierarchy.  We  can  extend  this  concept  to  an  even  higher  level,  and  take  advantage 
of  die  patterns  of  usage  for  high-level  graphics  functions  in  the  VGTS. 

In  a  distributed  graphics  system  the  processor  in  the  cache  model  plays  a  role  analogous  to  the  workstation, 
and  the  main  memory  corresponds  to  other  server  hosts.  'I’hc  performance  of  a  cache  can  be  roughly 
characterized  by  four  numbers: 

^  local  average  time  for  access  to  the  smaller  but  faster  resource. 

^rcmoic  average  time  to  reference  tlic  larger  but  slower  resource. 

T„  is  the  time  it  takes  to  communicate  between  tlic  Iwal  and  remote  resources. 

comm 

p  is  the  “hit"  rate,  or  probability  that  an  average  operation  can  be  handled  by  the  local  resource. 

This  large  communications  (actor,  !  is  the  major  di (Terence  from  tlic  hardware  Gichc  model,  along  with 
another  component  tliat  is  common  to  both  local  and  remote  operation: 

Tygjj  is  the  average  time  taken  by  the  VG'I'S  for  both  local  and  remote  operations. 

The  average  time  for  all  operations  is  then: 

avg  =  P  '’’local  +  -  PX  +  '’'remote^  +  '’’vgts 

I'hc  ideal  would  be  to  minimiz.c  tliis  time  with  respect  to  the  various  hardware  and  so(\warc  trade-offs 
mentioned  in  the  rest  of  tliis  chapter. 


62 


PARTITIONING  OF  FUNCTION  IN  A  UISTRIBUTI-I)  GRAPHICS  SYSTIiM 


In  more  concrete  terms,  this  model  represents  a  terminal  by  making  p  zero  (or  very  small),  so  no  operations 
are  performed  locally.  The  terminal  role  is  acceptable  when  and  1  are  small  components  of  the 
overall  cost,  which  implies  a  very  fast  mainframe  and  high-bandwidth  communication  (or  batch-oriented 
tasks).  When  p  is  near  one.  this  models  the  personal  computer  configuration.  Personal  computers  arc  fastest 
when  Tj^  is  small,  which  implies  fast  personal  computers  (or  simple  interactive  tasks). 

When  the  task  is  too  large  to  be  handled  by  the  personal  computer  or  terminal  configurations,  tlic  following 
approaches  can  make  smaller: 

1.  Reduce  (communication  time)  by  using  special  proUKols  or  network  improvcmciiLs.  'I'his 
requires  measurements  to  determine  if  the  actual  bandwidth  of  tlic  network  or  tlic  transport 
protocols  arc  the  bottleneck. 


2.  Reduce  by  using  a  faster  workstation.  As  we  will  sec  by  the  measurement  results,  speeding 

up  the  processor  usually  has  the  desirable  sidc-cffcct  of  also  increasing  effective  network 
throughput,  or  reducing  However,  this  cost  must  be  incurred  on  every  workstation. 

3.  Reduce  by  using  a  larger,  faster  computer  for  the  server  host.  This  cost  can  be  shared 

among  all  the  workstations  sharing  a  server. 


4.  Increase  p  by  caching  information  on  the  workstation  or  using  high-level  short  circuiting  so  that 
more  operations  can  be  performed  locally.  Applications  could  also  partition  themselves  to  put 
more  of  their  functionality  on  the  workstation.  Note  that  this  usually  implies  an  increase  of  the 
memory  of  each  workstation. 


5.  Reduce  T  by  improving  the  performance  of  the  VGTS  itself.  In  fact,  for  many  simple 
applications  with  insignificant  computation  demands,  this  factor  could  be  the  only  important  one. 

The  value  of  short-circuiting  has  already  been  introduced.  The  next  section  goes  into  more  detail  on  the 
relationship  between  the  local,  remote,  and  communication  times  in  the  VG'l'S  model. 

5.3.2  The  Time  Dimension 

VG  i'S  performance  can  also  be  examined  by  viewing  tlic  events  along  tlic  lime  dimension,  i’igurc  5-3 
illustrates  the  time  used  on  each  pnx:cssor  resource  for  one  typical  intcraclion  response  cycle.  Time 
progresses  IVoni  lell  to  light.  'Hie  fiint  example  is  a  personal  computer  coiillguralion.  'Hie  next  two  lines 
represent  the  partitioning  of  the  problem  between  a  workstation  and  u  server  host. 

riie  variables  in  Figure  5-3  represent  tlie  following  values: 

Tjnpm  Represents  the  time  to  handle  the  input  event.  This  is  usually  the  same  in  both  the  local  and 
distributed  case. 

^Swapln  Represents  the  time  to  swap  in  or  otherwise  change  contexts  to  the  application  program  on  the 
worksUition. 
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Figure  5-3;  Simple  request-response  time  model 

^Nctln  Represents  the  time  to  send  the  input  event  from  the  workstation  to  the  seiver  host,  for  the 
server  to  receive  iL  and  possibly  schedule  and  change  context  to  the  computation. 

Tp^,  Is  the  time  for  the  computation  to  be  executed  on  the  workstation. 

^  Server  computation  on  a  server.  Usually  execution  of  the  computation  is  faster  on  a 

larger  central  server  host  than  tlic  individual  workstation. 

^  SwapOui  R^^Presents  the  time  to  swap  out  the  application  program,  or  change  context  back  to  the  graphics 
system. 

^  NciOui  Represents  the  time  to  send  the  results  from  the  server  host  to  the  workstation,  for  the 
workstation  to  receive  it,  and  possibly  schedule  and  change  context  to  the  display  process. 

^Display  Represents  the  lime  to  display  tlic  result  of  tlic  interaction. 

'Ilic  conclusion  from  Figure  5-3  is  that  it  is  faster  to  use  the  workstalion/scrvcr  split  when  the  swap  times 
plus  the  local  computation  lime  is  longer  than  the  round-trip  network  overhead  plus  tlic  host  computation 
time.  That  is; 

T  4-  T  4-  T  >  T  +  T  +  T 

'Swapin  '  PC  ^  '  SwapOul  '  ’  Nciln  'Server^  NciOut 

is  tlic  condition  for  superior  performance  of  tlic  partitioned  configuration. 

Since  the  V-Syslcm  at  the  lime  of  this  writing  supports  neither  paging  nor  swapping.  I  is  either 
insignilkanl  (for  programs  already  fully  loaded)  or  else  it  is  tlic  lime  to  load  Uie  application  program. 
Similarly.  I  ^  context  switch.  On  the  other  hand,  for  die  applications  mentioned  in 

Section  1.2.2  that  must  run  on  the  server,  the  swap  limes  are  essentially  infinite.  On  most  personal  computer 
operating  systems,  swap  times  can  be  as  high  as  several  hundred  milliseconds.  Hven  without  physical 
swapping,  many  operating  systems  have  long  context  switching  times. 

The  time  dimension  analysis  suggests  the  following  techniques  to  improve  performanee; 

1.  Reduce  the  and  times  by  reducing  delay  in  the  network,  increasing  die  bandwidth 

of  the  network,  or  increasing  concurrency  in  the  network  overhead. 
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2.  Have  the  server  send  results  back  to  the  workstation  as  soon  as  possible,  since  the  rest  of  its 
computation  can  continue  in  the  background  concurrently  with 

3.  Use  the  personal  computer  approach  whenever  possible  with  high  timesharing  loads. 

Timesharing  loads  add  a  queuing  delay  to  which  could  easily  make  it  much  higher  than 

on  a  powerful  workstation. 

'ITiese  models  provide  the  framework  for  interpreting  the  performance  measurements  to  be  given  in  Chapter 
6.  The  following  sections  will  discuss  important  design  considerations  that  may  not  be  directly  related  to 
distribution  or  performance. 

5.4  Application  Multiplexing  Alternatives 

One  crucial  job  of  tlic  viewing  service  is  to  multiplex  the  single  user  and  display  devices  to  the  possibly 
many  application  programs.  'Hiis  function  is  similar  to  that  of  tlic  kernel  or  process  manager  of  a  general 
purpose  operating  system. 


5.4.1  Decentralized  Control 

Most  operating  systems  handle  contention  for  the  processor  by  letting  one  process  have  full  control,  then 
saving  die  state  of  the  proccs.sor.  loading  the  state  of  tlic  next  process  to  run,  and  letting  that  process  have  full 
control.  A  similar  approach  could  be  taken  with  graphics  [35].  Ihc  reasoning  is  that  this  will  allow  higher 
performance,  since  compiled  programs  usually  have  better  performance  than  interpreted  programs. 
However,  it  is  not  necessary  to  have  decentralized  control  to  have  compiled  display  lists;  it  is  just  a  question  of 
whether  the  application  program  or  the  viewing  service  docs  the  compiling. 

A  number  of  sophisticated  object-oriented  window  systems  have  been  built  for  personal  computers  with 
decentralized  ctintrol,  as  discus.scd  in  Section  2.2.  While  these  window  system  approaches  work  well  for  local 
applications,  they  do  not  extend  well  to  remote  applications,  especially  tliosc  written  outside  the  framework  of 
the  particular  language  and  worksbition.  Hven  systems  that  attempt  to  provide  Uic  object-oriented  “up-call" 
functionality  in  a  distributed  environment  have  resulted  in  centralized  control  [59]. 

One  major  problem  with  decentralized  control  is  tliat  current  graphics  devices  do  not  always  allow  the  state 
of  the  graphics  device  to  be  saved  and  restored.  Another  problem  is  tliat  application  programs  would  be 
non-portable  at  the  binary  level  even  if  there  were  workstations  that  used  the  same  proccs.sor  architecture  but 
different  graphics  architectures.  Iliis  may  not  seem  like  a  problem  since  source-level  compatibility  could  be 
rcUiincd.  but  it  could  result  in  a  version  "explosion"  with  many  copies  of  every  graphics  application,  each  of 
which  must  be  maintained  in  parallel  with  tlie  others.  Since  both  of  these  problems  existed  for  llie  SUN  and 
Iris  workstations.  Uie  deceiurali/ed  appro;ich  was  not  |)os.siblc  for  the  prototype  implementation,  llie 
original  motivation  for  virtual  terminals  (see  Section  2.3)  was  to  eliminate  tlie  /i  J  ni  version  problem. 


5.4.2  Centralized  Control 

'Hie  VGTS,  on  the  other  hand,  is  designed  to  operate  in  a  environment  composed  of  a  variety  of 
applications,  programming  languages,  m.nchines,  and  networks,  with  widely  varying  tenninal  interaction 
requirements.  A  centralized  approach,  rarely  taken  In  biunap  graphics  systems,  communicates  a  list  of  objects 
to  be  drawn  to  the  viewing  service,  and  tlie  viewing  service  actually  renders  the  objects.  Iliis  virtual  terminal 
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approach,  previously  introduced  in  Section  2.3,  was  taken  in  the  VG  I  S  due  to  the  advantages  for  portability 
and  partitioning. 

It  is  not  a  contradiction  (as  it  might  seem)  that  partitioning  implies  centralization.  Centralized  control  was 
used  in  the  VGTS  to  provide  adequate  performance  despite  expensive  communication.  The  actual  costs  of 
communication  will  be  measured  in  Chapter  6.  Another  side  benefit  of  centralization  is  conservation  of 
memory.  Kach  application  program  is  smaller  because  it  does  not  need  to  be  linked  with  the  graphics  library. 


5.5  Uniformity  and  Portability 

Another  set  of  issues  concerns  different  aspects  of  uniformity.  ITic  general  problem  ass(x;iated  with 
uniformity  is  that,  almost  by  definition,  uniformity  may  restrict  flexibility.  The  goal  was  to  restrict  how  things 
arc  done,  but  not  what  can  be  done. 


5.5.1  Device  Independence  of  Applications 

Since  workstation  hardware  is  changed  constantly,  software  developed  on  one  kind  of  workstation  usually 
docs  not  run  on  other  workstations.  One  traditional  approach  to  this  problem  have  been  query  operations. 
Application  programmers  may  take  advantage  of  query  operations  to  change  behavior  depending  on  the 
results  of  die  query  [28].  This  is  a  highly  restricted  form  of  device  independence,  that  requires  premeditation 
by  tlic  applications  programmer  of  all  possible  devices  with  which  the  program  will  ever  run. 

Device  independence  has  been  recognized  as  a  goal  for  quite  some  time,  but  is  even  more  important 
today  (60).  In  facL  technology  can  progress  so  fast  that  by  the  time  an  application  is  finished.  toUilly  new 
graphics  devices  may  be  available  that  were  not  even  anticipated  at  tlic  time  the  application  was  designed. 

For  example,  the  prototype  VG’I’S  took  about  one  year  to  develop,  another  year  to  measure  and  a  final  year 
to  evaluate.  In  tlic  meantime,  the  architecture  of  the  SUN  workstation  had  changed  drastically,  so  the 
prototype  implementation  no  longer  worked  on  the  new  workstation.  If  die  VGTS  architecture  had  been 
tailored  to  die  original  workstation,  then  all  the  applications  developed  during  diese  years  would  have  to  be 
rewritten.  Instead,  as  S(K)n  as  the  new  version  of  the  VG  I  S  diat  handled  die  new  workstation  was  installed,  all 
client  programs  could  be  run  immediately,  without  any  modifications.  VG  I  S  changes  were  limited  to  one 
low-level  module,  die  drawing  manager,  as  indicated  in  l-'igurc4-l. 


5.5.2  Uniformity  of  User  Interface 

In  addition  to  uniformity  across  difTcrent  hardware  devices,  unifonnity  across  different  software  tools  is 
another  desirable  goal.  Powerful  hardware  like  bitmaps  and  mice  provide  the  opporlunity  for  more  advanced 
interfaces,  but  also  can  cause  chatis  if  each  application  chwiscs  its  own  user  interface.  FWery  programmer  has 
his  own  idea  of  what  is  "right"  and  those  Listes  may  not  match  diosc  of  die  intended  users.  One  partial 
solution  to  this  problem  is  the  user  interfiice  management  system  concept  which  isolates  die  operation  of  a 
program  from  die  details  of  how  those  operations  are  invoked  1143). 

The  VG  rs  provides  a  step  in  this  direction,  with  the  following  user  interface  standards: 

•  Pop-up  menu  feedback  is  implemented  inside  the  VGTS.  'ITie  view  manager  menus  as  well  as 
diosc  provided  by  applications  arc  handled  uniformly. 

•  A  common  line  editor  provides  simple  editing  functions  like  character  and  word  delete  to  all 
applications  requesting  keyboard  input 
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•  Banners  provide  a  common  mechanism  to  indicate  some  concise  status  information,  such  as  the 
name  of  the  program  currently  executing. 

•  All  screen  management,  such  as  zooming  and  moving  of  views  is  done  uniformly  through  the  view 
manager. 

•  Other  conventions  and  library  packages  are  provided  as  suggestions.  For  example,  pressing  all 
three  buttons  simultaneously  signals  an  abort  to  most  programs. 

'fhe  result  is  that  users  quickly  learned  how  to  use  new  tooLs,  instead  of  having  to  adapt  to  the  whims  of  the 
implementor  of  the  new  tool. 


5.5.3  Portability  of  Implementation 

It  was  found  to  be  easier  to  modify  the  code  of  tlie  first  implementation  to  handle  another  kind  of 
workstation  than  to  start  from  scratch.  Several  techniques  were  used  to  aid  in  portability: 

•  Restricting  the  range  of  hardware.  In  our  case,  the  VGTS  was  targeted  to  higher-end  workstations 
and  future  higher  performance  hardware  instead  of  the  lower  cost  popular  personal  computers 
currently  being  mass  produced. 

•  Using  a  high  level  language.  ITie  VGTS  was  written  in  the  C  programming  language  [71].  C 
compilers  are  widely  available  for  many  computer  architectures.  The  Unix  timesharing  system 
has  been  ported  to  many  different  architectures  successhilly  by  using  C  [66]. 

•  Using  a  standard  computer  architecture.  ITie  prototype  VGTS  implementation  was  on  the 
Motorola  MC680(X)  architecture,  which  has  several  different  implementations  used  in  many 
commercial  products  [100]. 

•  Attention  to  modularity  and  isolation  of  machine  dependencies.  This  was  only  achieved  by 
actually  supporting  two  or  more  devices  with  the  same  source  code.  Once  the  system  worked  on 
two  machines,  the  third  was  easier,  and  so  on.  Ihe  first  few  efforts  detected  subtle  hidden 
machine  dependencies  that  would  otherwise  be  overliMtked,  such  as  byte  ordering  problems  [40J. 

Portability  was  another  of  many  properties  greatly  helped  by  economy  of  features.  A  small  system  was 
inherently  easier  to  port  titan  a  larger  system.  For  Utis  reason  many  attractive  features  were  not  included  in 
the  VG'fS  design  unless  they  were,  found  to  be  necessary.  For  example,  some  users  requested  up/down 
encoding  of  the  keyboard,  or  advanced  support  for  special  function  keys.  Unfortunately,  the  implementation 
already  worked  with  about  ten  types  of  keyboards,  sttme  of  which  did  not  have  up/down  encoding  or  special 
function  keys. 

Although  the  trend  to  faster  but  cheaper  graphics  workstations  is  unmistakable,  the  lime  between  the  start 
of  a  design  and  its  production  is  usually  underestimated.  For  example,  a  major  computer  inanufiicturer 
announced  a  workstation  product  and  demonstrated  it  in  July  of  1982.  In  the  fall  of  1982,  a  research  contnict 
with  Stanford  was  negotiated  that  included  porting  the  VG’I'S  to  Utis  new  workstation.  By  the  summer  of 
1984  the  project  shifted  efforts  to  a  newer  kind  of  worksbition.  J  lardwarc  progress  had  been  st>  gicat  llrat  the 
workstations  were  obsolete  before  lliey  were  delivered. 

A  more  important  problem  with  porting  the  VG'I'S  was  not  technological  but  political.  Most  workstation 
manufacturers  were  unwilling  to  reveal  low-level  deUiils  of  their  graphics  devices.  If  they  contained  custom 
hardware,  the  manufacturer  wanted  to  protect  the  trade  secrets  involved  in  tlic  hardware,  so  other 
manufacturers  could  not  use  the  same  techniques.  If  the  graphics  devices  were  simple  frame  buffers  driven 
by  software,  the  low-lcvel  raster  operation  functions  were  propricUiry,  to  prevent  Uic  use  of  the  software  on 
other  machines.  In  our  case  we  had  no  desire  to  pirate  trade  secrets,  but  we  failed  to  convince  the 
manufacturers  that  it  was  in  their  best  interests  to  give  us  the  information. 
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5.6  Customizability 

Unfortunately  the  goal  of  uniformity  was  in  direct  conflict  with  that  of  customirability.  Although  at  first 
customizability  seems  attractive,  there  arc  many  hidden  costs.  For  example,  people  often  work  together  on  a 
single  project  in  a  research  environment.  Highly  customized  interfaces  make  exchange  more  difficult,  if  users 
cannot  use  their  custom  commands  on  other  workstations.  On  the  other  hand,  since  researchers  arc  often 
systems  programmers  tlicmscivcs,  they  have  irresistible  urges  to  change  a  program  that  tlicy  do  not  like.  If  tlic 
interfaces  arc  not  designed  carefully  and  flexibly  enough,  users  will  develop  tlicir  own  versions  of  the  system 
anyway  and  the  goal  of  uniformity  is  lost. 

5.6.1  Customizability  by  Programs 

The  author  of  a  program  may  want  to  specify  some  slightly  device-dependent  “hints”  about  the  display 
process,  l-'or  example,  a  program  may  have  information  on  the  size  of  some  object  or  its  desired  location  on 
the  screen.  The  program  may  also  wish  to  advise  the  VGTS  on  how  the  objects  should  be  viewed.  Although 
the  VG  TS  architecture  allows  such  hints,  only  one  was  provided  in  the  prototype  implementation:  An 
application  can  declare  the  size  of  a  default  view. 

One  example  of  a  programmer  who  wanted  customiz.ation  of  the  viewing  process  occurred  in  an  integrated 
VLSI  layout  editor  and  design-rule  checker.  'ITic  author  of  such  a  program  requested  the  ability  to  position 
an  item  within  a  view,  so  that  a  design  rule  violation  could  be  centered  in  the  viewport.  Such  a  feature  could 
easily  be  added  by  creating  another  VG  f  with  the  item  as  its  top-level  symbol,  and  then  defining  another 
default  view  with  the  desired  coordinates.  Ilie  view  manager  could  also  include  commands  to  center  a  view 
on  coordinates  typed  by  a  user,  instead  of  pointed  to  by  the  mouse.  'ITierefore,  tlic  view  manipulation 
capabilit)'  was  not  added  to  the  VGTS  client  interface. 

A  common  argument  is  that  programs  should  be  able  to  perform  any  function  that  a  user  can  perform.  This 
is  not  provided  in  the  current  VG'I'S,  since  the  user  interface  deals  with  views  and  physical  screens,  while  the 
application  interface  intentionally  hides  these  objects  and  deals  with  graphical  items  and  virtual  terminals. 
One  area  of  future  research  is  tlie  design  of  a  different  kind  of  interface  tJiat  could  be  used  for  customized 
view  management.  However,  it  is  important  to  make  the  clear  distinction  between  non-uniformity  on  the  part 
of  die  application  tools,  and  customization  of  those  tools  on  the  basis  of  tlie  user. 

5.6.2  Customizability  by  Users 

A  user  may  want  to  specify  a  profile  to  tailor  certain  aspects  of  the  user  interface  to  his  or  her  needs.  For 
example,  novice  users  may  want  an  interface  that  is  easier  to  learn  or  in  which  it  is  harder  to  make  mistakes, 
while  expert  users  want  more  powerful  interfaces  with  commands  available  quickly.  In  addition,  many 
aspects  of  user  interfaces  arc  a  matter  of  personal  taste.  With  respect  to  screen  managemenL  some  people 
prefer  to  use  arbitrarily  overlapped  viewports  as  implemented  by  the  proioiypc  VG  TS.  while  others  prefer  to 
use  the  filed  approach,  in  which  the  view  man.igcr  causes  views  to  exactly  fill  the  screen  wilhout  j)vcrlap  [1401. 
Another  open  question  is  the  proper  form  of  menus.  In  die  current  implementation,  one  button  dick  causes 
the  menu  to  appear  and  another  causes  the  selection.  This  reduces  tlie  probability  of  errors  when  incorrect 
button  combinations  arc  given,  but  requires  two  user  actions  for  each  menu  selection.  Other  systems  cause 
the  menu  to  appear  when  the  button  is  prcs,scd.  and  the  selection  to  occur  when  the  button  is  released. 

Some  systems  use  profiles  on  a  workstation  or  application  basis,  but  they  should  really  be  provided  on  the 
basis  of  user,  since  users  and  applications  should  be  able  to  use  any  workstation.  Ihc  VG  I  S  architecture 
allows  this  customizxition  of  the  view  management  process,  but  the  current  implementations  do  not  realize  tliis 
capability.  Partially  tliis  is  due  to  the  lack  of  a  user  identification  concept  in  the  current  V-System,  but  also 
due  to  tlie  fact  that  the  conventions  as  implemented  have  proven  reasonable  in  actual  use. 
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5.7  Suitability  for  the  Future 

The  future  in  the  computer  industry  is  hard  to  predict  in  detail,  but  some  general  trends  are  certain.  We 
wanted  to  take  advantage  of  these  trends  whenever  possible,  instead  of  tying  the  design  to  technology  that 
would  quickly  become  obsolete. 


5.7.1  Future  Display  Devices 

l.arger,  faster  biunaps,  and  special-purpose  graphics  hardware  should  become  less  expensive  in  the  future. 
For  example,  while  this  diesis  was  in  preparation,  die  Apple  Macintosh  was  made  available  for  about  $1000 
with  a  University  discount;  this  is  less  than  most  alphanumeric  terminals.  The  Macintosh  has  a  fairly  small 
display  screen  and  low-performance  processor,  but  die  mere  existence  of  die  mouse  and  bitmap  display  in  a 
mass-produced  product  arc  encouraging. 

'Hie  Iris  workstation  is  an  example  of  a  highcr-pcfformancc  and  therefore  higher-cost  system,  with  custom 
hardware  applied  to  the  viewing  process  [39].  The  current  IRIS  implcmcntadon  renders  the  output  primitives 
using  a  bit-slice  microprcKCSsor,  and  is  too  expensive  for  wide-spread  use.  However,  the  iRIS  is  indicative  of 
the  trend  to  applying  special-purpose  hardware  to  graphics  systems. 

Current  developments  include  “smart  memories”  that  use  special  devices  to  perform  rendering,  including 
anti-aliasing  and  shading  via  ray-tracing,  directly  in  die  frame  buffer  [63].  Pcrfonnancc  can  be  enhanced 
further  by  using  pipelining  and  parallelism.  With  this  kind  of  hardware  the  BitBlt  model  of  operations  breaks 
down.  Instead  of  moving  bits  around,  the  interface  to  die  hardware  is  at  a  higher  level:  declaring  primitive 
graphics  objects  like  vectors  and  polygons. 

There  arc  two  differing  opinions  on  the  effect  of  this  advanced  specialized  hardware.  One  line  of  reasoning 
is  that  since  all  this  custom  hardware  is  so  expensive,  die  raw  graphics  device  must  be  used  at  a  very  low  level 
to  avoid  wasting  any  power,  'Ihc  other  line  of  reasoning  is  diat  new  hardware  can  be  used  to  allow 
programming  at  a  higher  level,  with  straightforward,  simple,  and  elegant  approaches  replacing  the  special 
mechanisms  ncccs.sary  on  slower  hardware.  The  first  opinion  appeals  more  to  those  who  design  and  market 
the  hardware,  while  the  second  appeals  to  those  who  develop  the  software  and  use  the  worksuttions.  Since 
software  costs  arc  becoming  increasingly  more  important,  in  die  long  run  the  elegant  software  approach 
should  dominate. 

As  the  VGTS  was  designed,  it  was  hard  to  predict  what  the  future  held,  but  one  diing  was  certain:  there 
would  be  many  more  changes  in  the  kinds,  quality,  and  cost  of  graphics  devices.  One  good  way  to  take 
advantage  of  these  new  devices,  given  this  uncertainty,  was  to  use  abstract  high-level  interfaces  and 
concentrate  on  portability  as  done  in  the  Yd'S. 


5.7.2  Future  Computer  System  Organization 

Ironically,  die  personal  computing  Ircnd  may  be  short-lived.  Computer  systems  arc  still  expensive,  and 
people  can  not  alTord  fidly  configured  personal  computers.  On  die  other  hand,  microprocessors  arc  almost 
free,  and  getting  cheaper.  The  cost  of  a  microprocessor  should  eventually  approach  the  cost  of  a  memory 
integrated  circuit  so  despite  the  increasing  densities  of  memory,  the  trend  should  be  to  less  memory  per 
processor  instead  of  more  memory  per  processor.  The  result  should  be  computer  systems  that  consist  of  many 
microprocessors  working  together. 

For  example,  the  cluster  of  workstations  for  which  the  VGI'S  wtis  developed  consists  of  about  ten  diskless 
SUN  worksuitions  connected  with  a  local  network  to  three  Vax-11/750s.  one  Vax-1  1/780,  and  a  shared 
l)i:cSystcm-20.  In  fact  each  of  the  workstations  is  really  a  multiprocessor  in  its  own  right.  In  addition  to  the 
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MC68000,  there  are  simple  finite-state  machines  to  refresh  and  update  the  frame  buffer,  a  bit-slice  processor 
to  handle  the  HthcrncL  and  microprocessors  in  the  keyboard  and  mouse. 

For  these  reasons.  protcKols  that  treat  the  workstation  as  a  terminal  (that  is,  partitioning  below  the  VDI 
level  as  illustrated  in  Figure  2-2)  arc  not  very  interesting  for  the  future.  The  main  limitation  with  these 
prouxrols  is  that  they  assume  only  one  connection  at  a  time.  Since  future  computer  systems  will  probably 
have  many  prcKCssore,  and  a  single  user  will  probably  use  many  processors  at  once,  the  VG  I  S  should  allow  as 
much  concurrency  as  possible.  Concurrency  is  a  uschil  concept  both  at  the  hardware  level  (as  many 
computers  as  possible  should  be  kept  busy)  and  at  the  higher  levels  of  user  interface  (the  user  should  be  able 
to  have  many  tasks  in  progress  at  tlic  same  time).  As  a  first  step,  the  VG'l'S  provides  tlic  graphics  operations 
in  a  separate  pr(x:css,  instead  of  as  functions  called  by  die  application  programs. 

5.8  Backward  Compatibility 

Although  planning  for  the  future  is  important,  the  VGTS  design  did  not  ignore  the  pasL  It  is  unreasonable 
to  expect  all  software  to  be  rewritten  for  every  new  system.  For  diis  reason,  one  VGTS  goal  was  to  be  able  to 
take  advantage  of  as  much  existing  software  as  possible.  A  similar  approach  was  Uiken  in  the  Bruwin  virtual 
terminal  system  [96]:  the  terminal  manager  was  designed  to  take  Advantage  of  existing  tools,  instead  of  being 
the  f(x:us  of  all  new  developments.  Hven  though  Br'uwin  provided  support  for  only  text  on  a  conventional 
graphics  device  directly  connected  to  a  timesharing  system,  it  proved  to  be  a  useful  tool.  Sirrilarly,  the  VG'FS 
also  was  able  to  access  applications  running  under  the  Unix  timesharing  system  through  remote  execution. 

5.8. 1  Encapsulating  Existing  Facilities 

For  example,  the  V-Sysicm  itself  (including  the  VG'VS)  was  compiled  on  a  Vax/Unix  timesharing  system. 
Hventually  more  software  development  tools  were  ported  to  the  native  V-System  environment.  The  ability  to 
run  the  tools  under  Unix  greatly  eased  the  transition.  Many  specialized  or  proprietary  programs  are  still 
accessed  through  the  Unix  server  interface. 

In  addition,  through  the  use  of  terminal  emulators  and  user  lT:i.Nirr  programs,  a  VG'l'S  user  can  run 
applications  anywhere  throughout  the  Aki’A  Internet.  This  remote  terminal  capability  has  turned  out  to  be 
one  of  the  most  heavily  used  features  of  tlic  current  implementation.  The  next  chapter  will  describe  some 
experiments  using  even  interactive  graphics  programs  in  this  manner.  Fortunately,  many  tools  can  be 
accessed  in  a  batch  fashion,  so  there  is  little  performance  degradation  when  tlicy  arc  executed  remotely.  For 
example,  tliis  thesis  was  produced  with  a  dcKumcnt  compiler  that  ran  on  a  UNIX  server  host 

5.8.2  Relation  to  Standards 

Another  way  of  taking  advantage  of  the  past  is  to  follow  standards.  The  graphical  facilities  of  tlic  VG'l'S  arc 
similar  to  those  several  existing  graphics  packages,  including  those  conforming  to  tlic  Core]  147]  and 
GKS  [64]  standardi/alion  cflbrts.  I'he  principal  din'creiiccs arc: 

1.  sLmdardized  support  for  object  modeling  as  well  as  viewing; 

2.  hierarchical  structure  of  objects; 

3.  the  ability  to  handle  multiple,  distributed  applications  simultaneously; 

4.  less  flexibility  in  tenns  of  attribute  and  cotirdinatc  transformation  facilities. 
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In  general,  the  standards  remain  oriented  toward  a  single,  dedicated  host,  and  pay  little  attention  to 
distributed  systems  issues,  especially  the  use  of  contemporary  powerful  biunap  workstations.  Furthermore, 
there  were  no  specific  applications  written  for  these  graphics  standards  that  had  to  be  supported  by  the 
VG'I’S.  Therefore  the  VGTS  did  not  conform  to  any  of  these  standards. 

Some  recent  graphics  efforts  arc  more  in  the  spirit  of  the  VGTS.  Both  NGS[24]  and  HillGS[4],  for 
example,  extended  tlic  concepts  of  GKS  and  Core  to  include  structured  display  files,  similar  to  the  VG'I'S.  As 
with  previous  standardization  efforts,  these  go  beyond  the  current  VG  I'S  in  support  for  attributes  and 
coordinate  transformations.  In  fact,  had  they  existed  at  the  time  die  VGTS  was  first  designed  (the  fall  of 
1981),  we  might  have  adopted  many  of  their  facilities  outright.  However,  neither  emphasizes  distributed 
graphics  (despite  its  name.  Network  Graphics  System,  in  the  ease  of  NGS)  or  multi-application  (window 
system)  facilities. 

1’able  5-1  summarizes  how  the  VGTS  graphics  capabilities  compare  to  some  traditional  graphics  packages. 
The  first  column  gives  the  name  of  the  graphics  package,  and  the  second  gives  die  number  of  dimensions  in 
most  operations.  The  next  column  indicates  the  kind  of  structures,  including  no  retained  segments  in  minimal 
GKS,  simple  one-level  segments  in  CORE  and  GKS,  execute  segments  (like  procedure  calls),  and  copy 
segments  (like  macro  expansions).  The  next  column  gives  the  approximate  number  of  functions,  which  is 
always  larger  than  the  small  number  of  graphics  primitives.  T'he  last  column  gives  the  approximate  years 
during  which  die  ddsign  took  place. 


lauiBnmTC^l 

Core 

3D 

Segments 

227 

1977-1979 

GKS  Maximal 

2D 

Segments 

185 

1978-1982 

GKS  Minimal 

2D 

None 

48 

1981-1982 

NGS 

3D 

Copy/Exa:ute 

181 

1982-1984 

PlIIGS 

3D 

Copy/Exccute 

180 -F 

1983-1985 

VG'I'S 

2D 

Execute 

30 

1982-1984 

Table  5-1:  Comparison  of  graphics  packages  to  VG’I'S 


The  Virtual  Device  Interface,  VDl,  could  be  used  as  a  real  terminal  protocol  in  die  VG'I’S,  by  developing  an 
SDF  interpreter  that  would  generate  VDI  commands.  The  Siime  observations  hold  with  respect  to 
NAI’I.PS  (b|.  I'his  would  allow  a  single  VGTS  implemcntiition  for  all  devices  meeting  the  specification.  An 
interesting  question  is  whether  all  device  dependencies  should  be  below  die  VDI  (or  equivalent)  layer,  or  if 
common  code  could  be  used  to  simulate  die  commonly  missing  hardware  capabilities.  For  example,  the  code 
to  handle  dashed  lines  for  devices  having  only  solid  lines',  could  be  written  once  instead  of  inside  each  device 
driver.  I'hcre  seems  to  be  an  unwritten  rule  that  if  a  graphics  device  has  any  special  hardware  capabilities, 
then  these  “features"  must  be  used,  at  almost  any  sitcrifice  in  stillware  structure.  I'his  could  cause  problems  if 
devices  are  supported  that  provide  graphics  primitives  in  hardware  diat  are  not  included  in  die  VG'I'S 
architecture. 

5.9  Summary  and  Motivation  for  Measurements 

I'his  Chapter  discus.scd  the  reasons  behind  the  major  design  decisions  taken  in  die  VGTS.  I’he  next 
Chapter  attempts  to  quantify  the  degree  of  these  trade-offs.  For  example,  the  stnetured  display  file  approach 
favors  highly  structured  pictures,  and  incremental  editing  over  initial  display.  I'he  penalty  for  initial  display 
and  unstructured  pictures  should  be  small  compared  to  the  improvement  for  structure.  Since  total  system 
performance  was  considered  important  diroughoul  die  design,  some  simple  models  were  developed  and 
examined  in  this  Chapter.  The  models  show  that  performance  can  be  improved  by  reducing  the  frequency  of 
communication  and  the  amount  of  information  communicated. 
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The  centralized  control  of  the  VGTS  has  benefits  for  uniformity  and  portability,  but  still  allows  some 
customizjition.  Partitioning  as  exemplified  by  the  VGTS  should  become  more  important  as  future  display 
and  computing  devices  are  introduced.  On  the  other  hand,  users  should  be  isolated  from  changing  hardware 
by  encapsulation  of  existing  facilities  and  adherence  to  standards.  Experiments  arc  also  needed  to  prove  that 
performance  is  adequate  compared  to  tlic  older  systems  being  emulated  and  replaced. 
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—  6  — 
Measurements 

’nic  previous  chapter  discussed  many  qualitative  advantages  of  the  VG  I  S  design,  such  as  portability  and 
suiuibility  to  future  hardware.  Quantitative  measures  arc  also  desired  to  provide  a  firm  basis  for  evaluation. 
One  ultimate  measure  of  a  system’s  success  is  whether  people  choose  to  use  it  to  get  work  done,  even  in  a 
research  project.  I’his  criterion  certainly  applies  in  the  ease  of  tlic  VG  I  S.  since  the  high  level  of  interaction 
enforced  by  the  VG  TS  may  trade  off  some  functionality,  flexibility,  or  performance.  If  the  amount  of  these 
qualities  U  st  is  small  enough  compared  to  the  advantages  gained,  tlicn  tlic  approach  may  be  worthwhile  for  at 
least  some  class  of  applications. 

I'or  example,  some  graphics  tcnninals  allow  special  effects  like  limited  animation  using  tricks  with  the  color 
map.  On  a  workstation  shared  with  other  applications,  these  special  mechanisms  cannot  be  used,  since 
resources  like  the  color  map  arc  shared  between  several  different  applications.  This  chapter  will  show  that 
careful  design  of  VG  TS  proUKols  can  make  performance  acceptably  close  to  that  of  other  systems  that  do  not 
have  the  advantages  of  the  VGTS. 

6.1  Nature  of  Performance  Measurements 

Performance  measurements  have  been  taken  for  three  benchmark  programs,  two  for  graphics  and  one  for 
text,  in  a  variety  of  test  configurations.  In  addition,  the  illustration  editor  used  to  create  the  diagrams  in  this 
diesis  was  instrumented  to  measure  memory  usage,  construction,  and  display  rates. 


6.1.1  Benchmark  Programs 

The  first  graphics  benchmark  created  a  fully-connected  36-agon  with  a  radius  of  350  pixels,  drawing  630 
vcctois  or  288,364  pixels.  Thus  the  average  vector  si/e  in  diis  benchmark  was  457  pixels.  Since  the  picture 
was  a  fully-connected  polygon,  many  different  angles  of  vectors  were  used.  Ihis  was  intended  to  test  the 
performance  of  traditional  vector  graphics  functionality.  The  action  was  repeated  ten  times,  and  the  numbers 
listed  are  die  mean  often  consecutive  trials. 

All  numbers  given  as  vectors  per  second  in  this  chapter  refer  to  this  same  artificial  benchmark,  so  they 
should  be  valuable  for  relative  comparisons  but  not  absolute  limits.  However,  since  most  significant 
computation  was  done  before  the  limed  parts  of  this  program,  and  the  number  of  items  in  die  picture  is 
relatively  large,  the  intent  was  to  measure  the  peak  rales  of  adding  items  to  a  symbol  and  then  drawing  dial 
symbol.  I  his  would  measure  die  rale  of  initially  drawing  a  new  picture. 

Hie  second  graphics  benchmark  was  intended  to  test  the  effects  of  using  structure  on  a  simple  picture  of  the 
kind  used  in  a  VI, SI  layout  editor |42|.  Ibis  benchmark  drew  an  array  of  five  by  six  NMOS  inverters [93]. 
l  ach  of  these  .10  inverters  consisted  of  26  rectangles,  for  a  lot.il  of  780  rectangles,  all  filled  with  one  of  four 
stipple  patterns  (which  would  appear  as  colors  in  a  color  iniplcmenlalion)  representing  the  four  NMOS  layers, 
f  irst  the  picture  was  drawn  using  a  single-level  SDI'  and  adding  all  780  rectangles  individually.  Ilie  second 
part  of  this  test  defined  a  contact  cut  symbol,  then  an  inverter  symbol,  and  dien  added  30  calls  to  the  inverter 
symbol,  with  only  23  primitive  items  in  the  SDK. 

Although  the  regularity  factor  this  drawing  (the  ratio  of  todil  items  divided  by  defined  items,  or  30  in  this 
case)  is  fairly  high,  modern  VLSI  designs  typically  have  regularity  factors  in  llie  stime  range,  and  Uie  trend  is 
to  increasing  regularity  |83.  84],  In  fact,  many  of  llic  designs  currently  under  development  could  never  be 
possible  with  smaller  regularity  factors.  Independent  of  Uie  structure,  Uie  resulting  image  was  Uic  same,  about 
400  pixels  on  a  side. 
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'Fhc  text  benchmark  programs  simply  wrote  characters  until  stopped  by  the  user.  This  behavior  would 
occur,  for  example,  when  displaying  a  new  page  in  a  text  editor.  The  characters  were  from  a  fixed-width  font 
with  each  character  eight  pixels  wide  and  16  pixels  high,  or  128  total  pixels  per  character.  This  was  the 
standard  font  used  by  most  applications  except  those  doing  specialized  text  display.  It  was  developed  by  the 
author  by  manually  editing  the  output  of  the  Miri  Ai-ONT  type  design  program  [74]. 


6.1.2  Test  Configurations 

'fhe  actual  structures  of  the  protocols  and  programs  used  in  the  performance  measurements  arc  illustrated 
in  Figures  6-1  and  6-2.  Ihc  benchmarks  were  conducted  with  the  following  communication  configurations: 

Local  Application  running  on  die  same  workstation  as  the  one  used  for  display.  Ihe  application  sends  V 
messages  directly  to  die  VGTS.  Since  the  application  is  on  a  separate  team  (address  space),  the  V 
kernel’s  data  transfer  operations  arc  needed  to  move  information  from  the  application  to  the 
VG'I'S’  address  space:  no  shared  memory  is  used.  This  is  illustrated  in  Figure  6-la. 

SuN-iKH  Application  running  under  the  V-system  but  on  a  different  machine,  connected  via  Kthcrnct  to 
another  workstation,  and  using  V-System  IKP.  As  illustrated  in  Figure  6- lb,  this  involves  the 
application  using  the  same  message-passing  interface,  but  with  kernels  implcmcntirlg  the  Inter- 
Kernel  Protocol. 


Vax-ikp  Application  running  under  Vax/Unix,  connected  via  Ethernet  to  the  workstation,  and  using 
V-System  IKP.  As  illustrated  in  Figure  6- 2a,  this  involves  the  application  writing  to  a  pipe,  which 
is  read  by  the  V-server  program,  which  sends  messages  over  the  network  to  a  V  kernel.  The 
workstation  runs  a  simple  program  called  fexecute  which  is  necessary  only  because  both  the 
VGTS  and  die  V-server  arc  servers;  they  both  arc  sent  messages  to  which  dicy  reply,  instead  of 
►  initiating  the  sending  of  messages  by  themselves. 


Pup  Application  running  under  Vax/Unix,  connected  via  Ethernet  to  the  workstation,  and  using  Pup 
Ti'.i.nci.  Figure  6-2b  illustrates  diis  configuration.  The  application  uses  pseudo-tty  devices 
(ptys)  to  communicate  with  the  PUP  Ti:i,net  server  program  Telser.  ’Ihis  program  sends 
packets  over  the  network  to  the  workstation,  where  a  user  PUP  ri-I.Nirr  program  sends  the 
messiiges  to  the  VG  I  S. 


E-IP  Application  running  under  Vax/Unix.  connected  via  Ethernet  to  die  workstation,  and  using 
Internet  ri'l.Nl-T.  'Ihis  is  Figure  6-2c.  The  application  again  uses  pseudo-tty  devices  to 
communicate  with  the  IP  ri;i.Nl-*r  server  Telnetd.  The  implementation  of  the  transport 
protocol  in  diis  case  is  in  die  Unix  kernel,  and  a  separate  program  called  the  Internet  Server  on 
the  workstation.  Ihe  user  ri:i  .Ni:r  program  finally  sends  the  mcssiigcs  to  the  VG'I'S. 

A-IP  Application  running  under  Vax/Unix.  connected  via  i-.lhcrnct  and  ARRANIT  to  die  worksUition, 
and  using  Internet  Ti  l  ni  i  .  This  is  the  Siinie  as  l•■igllrc  6-2c.  but  with  network  including  a  gateway 
and  an  extension  dirough  the  AKl’ANiri  backbone. 


rests  were  conducted  using  sUindard  10  Mbit/sccond  Ediernet  unless  otherwise  noted.  Tests  were  also 
perlormed  on  the  experimental  3  Mbit/sccond  Edicrncl  [41].  Eiich  configuration  used  workstations  with  both 
8  and  10  M  Hz.  MC68000  prcKCSSors.  For  configurations  involving  Vax-1  Fs.  750's,  780’s,  and  a  785  were  used, 
and  the  tests  were  conducted  during  uns(x;iablc  hours  with  correspondingly  light  loads.  Real  applications  arc 
oficn  run  with  high  timesharing  loads,  but  these  arc  hard  to  control  for  die  sake  of  die  experiments. 


Even  more  difficult  to  control  were  changes  to  underlying  software.  Some  variation  through  time  inevitably 
occurred  in  die  VG'I’S,  other  workstation  software,  and  host  software.  For  example,  introducing  new  features 
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Application 


VQTS 


VQTS 


a)  Local 


b)SUN-IKP 


Figure  6- 1 ;  Workstation  configurations  tested 


(execute  PUP  Telnet 


a)VAX-IKP 


b)  PUP  Telnet 


earver 

c)  IP  Telnet 


Figure  6-2;  Server  host  configurations  tested 

and  fixing  errors  typically  reduce  performance,  while  easing  bottlenecks  found  during  experiments  improves 
performance.  Although  each  table  in  Utis  Chapter  ettmpares  configurations  with  similar  software,  two 
dificrent  tables  may  compare  dissimilar  versions.  'Hie  dcUtiled  resiilLs  in  Appendix  I)  include  the  date  of  each 
measurement. 


6.2  Summary  of  Performance  Results 

Given  the  declarative  nature  of  the  VG  TP.  some  measures  of  interest  arc: 
construction  rate  Hie  rate  that  objects  can  be  added  to  a  symbol,  without  any  display  operations. 
batch  rate  llie  rate  (hat  objects  can  be  added  to  a  symbol,  and  tlien  displayed. 
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incremental  rale  ilic  rate  that  objects  can  be  added  and  displayed  as  each  is  added. 

display  rate  'Hie  rate  that  objects  can  be  displayed  once  they  are  defined. 

Construction  rate  is  the  best  measure  of  the  peak  network  offered  load  for  distributed  graphical  applications. 
The  batch  rate  takes  into  account  display  overhead,  which  is  fairly  independent  of  the  network.  Nevertheless, 
it  gives  the  best  measure  of  overall  graphics  throughput.  On  the  other  hand,  tlic  incremental  rate  gives  a 
better  measure  of  expected  response,  when  interpreted  as  the  maximum  number  of  display  transactions  per 
second.  Display  rate  is  another  measure  of  response  for  operations  such  as  screen  rearrangement  or  redisplay 
of  defined  symbols. 

Unstructured  vector  graphics  performance  is  summari/cd  in  Table  6-1.  Additional  details  appear  in  the  rest 
of  the  tables  in  tliis  chapter  and  in  Appendix  I).  In  all  of  tltc  tables,  columns  arc  labeled  witli  the  test 
configurations  listed  above  (local.  SuN-lKP.  Vax-ikp,  PUP.  E-IP.  and  A-IP).  Most  rows  arc  labeled  with 
(speed,  host,  ra'c)  triples,  where  speed  is  the  speed  of  the  Sun  workstation  proccs.sor  (8  or  10  MUz).  host  is  the 
type  of  VAX  (750.  780.  or  785).  and  rate  is  one  of  the  rates  listed  above  (construction,  batch,  incremental,  or 
display).  All  numbers  arc  in  vectors  or  characters  or  rectangles  per  second,  so  larger  numbers  indicate  better 
performance.  KcsulLs  have  been  rounded  to  two  significant  digits,  and  should  be  taken  as  order  of  magnitude 
estimates  only,  due  to  the  many  factors  involved.  However,  as  wc  shall  sec,  even  these  very  rough 
measurements  can  be  helpful  to  determine  the  feasibility  of  this  approach. 

I’abic  6-1  presents  the  performance  figures  for  configurations  employing  the  most  common  processors,  10 
MHz  Sun  and  Vax-750.  As  shown  by  tlic  construction  rate  row,  objects  can  be  constructed  at  440 
vcctors/sccond  for  applications  running  locally,  and  380  vcctors/sccond  for  Rthemet-based  applications. 
Overall  graphics  throughput  as  shown  by  the  batch  rate  row,  is  220  vcctors/sccond  for  local  applications,  up 
to  350  vcctors/sccond  for  Ethernet-based  apiilications.  and  120  vcctors/sccond  for  ARPANirr-based 
applications.  Incremental  display  permits  62  vcctors/sccond  for  local  applications,  up  to  87  vcctors/sccond 
for  Flthcrnet-bascd  applications,  and  39  vcctors/sccond  for  ARl’ANl'l-bascd  applications.  Actual  display  rates, 
shown  in  Table  6-3.  arc  on  the  order  of  430  vcctors/sccond,  or  .2  million  pixcls/sccond,  or  5 
microscconds/pixcl  including  all  display  overhead. 


Vcctors/sccond 


BHiiSaH 

■1391 

■am 

■am 

10. 750,  construction 

440 

380 

200 

220 

130 

10. 750,  batch 

220 

350 

200 

220 

120 

10. 750.  incremental 

62 

81 

58 

87 

39 

Tabic  6-1 :  Summary  of  graphics  performance 


'fhe  text  results  arc  summarized  in  Table  6-2.  I'hroughput  is  7700  charactcrs/sccond  for  local  applications, 
up  to  4300  charactcrs/sccond  for  ItKal  net-based  applications,  and  1900  charactcrs/sccond  for 
Aki‘ani'1  -based  applications.  Additional  details  appear  in  'fables  6-4  and  6-5. 

Chanictcrs/sccond 

Conllcuration  _ liKal  IKP  l>lll>  IMP  A-IP 

10. 780,  text  7700  4300  1600  4300  1900 


Tabic  6-2;  Summary  of  text  performance 
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6.3  Feasibility  Evaluation 

The  most  gratifying  conclusion  is  that  tlic  VGTS  performs  better  than  many  systems  that  researchers  are 
currently  using.  I  raversing  the  structured  display  files  to  refresh  the  screen  is  within  25%  of  the  speed  of  the 
bare  hardware,  accessed  through  a  package  of  low-level  graphics  primitives  (22].  Symbols  can  be  constructed 
at  about  the  same  rate  as  they  can  be  displayed.  Lasdy.  as  shown  by  the  incremental  rate  row  in  Table  6-1, 
applications  may  issue  around  60  EditSyinbol  -  Add/tem  -  EndSymbol  sequences  per  second.  'ITiis  is  more 
than  tlic  10-20  updates  per  second  needed  to  make  limited  forms  of  animation  possible  at  the  application 
level,  without  any  need  to  resort  to  display  file  compilation  or  other  special  techniques.  Display  file 
compilation  is  still  possible  in  this  architecture,  and  may  be  needed  for  graphics  devices  that  are  faster  in 
relation  to  processor  speed. 


Graphics  pipeline _ Vectors/second 

1.  Local  application  -»  frame  buffer  (clever  code)  570 

2.  VGTS  -»  frame  buffer  430 

3.  Remote  application VGTS  frame  buffer  350 

4. 1 xKal  application  ->W  ->framc  buffer  300 

5.  Local  application  -^VG'IS  -♦framebuffer  220 

6.  Local  application  ->  frame  buffer  (straightforward  code)  190 

Table  6-3;  Effect  of  graphics  pipeline 

Perhaps  the  most  important  concern  is  how  the  VGI'S  performance  compares  to  more  traditional  graphics 
architectures.  Table  6-3  compares  a  number  of  different  “graphics  pipelines"  to  help  make  this  comparison, 
■fhe  pipelines  include  the  following: 

1.  An  application  writing  directly  to  the  frame  buffer  using  the  standard,  highly  optimized 
implementation  of  vector  drawing. 

2.  The  Vtj'fS  refreshing  the  frame  buffer  from  a  structured  display  file. 

3.  An  application  program  on  a  server  host  using  die  VGTS  to  construct  and  display  the  picture. 

4.  A  local  application  using  an  alternative  “Window  System”  [10].  This  is  an  example  of  the  more 
common  graphics  model  in  which  tlic  application  is  in  control  of  all  drawing. 

5.  An  application  program  on  the  worksuition  using  tlic  VGI'S  to  construct  and  display  tlic  picture. 

6.  An  application  writing  directly  to  the  frame  buffer  using  a  straightforward  implementation  of 
vector  drawing. 

Ily  comparing  the  performance  of  these  pipelines,  we  can  estimate  upper  bounds  on  tlie  cost  of  the  major 
architectural  features  of  the  VG  I  S.  Lines  1  and  2  show  about  25%  performance  degradation  for  all  drawing 
overhead  in  the  VG  I’S.  I  lic  principal  costs  arc: 

•  Coordinate  Iransroniialions.  Applications  specify  objects  in  a  virtual  c(H)rdinate  space,  which 
must  be  transformed  into  device  c<M)rdinates.  This  could  be  done  at  SDE  creation  time  using  a 
form  of  display  file  compilation,  but  is  currently  done  at  draw  time,  avoiding  the  use  of  expensive 
aritlimetic  operations  like  multiplications  by  using  shifls. 

•  Gipping.  Objects  arc  displayed  only  within  window  boundaries.  Objects  tliat  lie  entirely  outside 
of  the  window  should  not  be  displayed,  but  the  parts  of  objects  that  lie  partially  within  the 
window  should  still  appear. 

•  SDR  Interpretation.  'Die  SDF  structure  was  designed  to  be  interpreted  very  quickly.  With  an 
overhead  of  one  pointer  reference  per  item,  tliis  constitutes  very  little  of  tlic  drawing  overhead. 


A'S.'A-. 


y  v>:v 


78 


PARTITIONING  01-  FUNCTION  IN  A  DISI  RIBUl  ED  GRAPHICS  SYSTEM 


Lines  1  and  4  can  be  used  to  estimate  the  cost  of  centralized  control.  The  W  system  is  representative  of  the 
“minimalist”  approach,  with  actual  drawing  centralized  but  few  of  the  otlier  features  of  the  Yd'S.  Thus  the 
47%  overhead  of  W  can  be  attributed  primarily  to: 

•  Message  overhead.  This  will  be  incurred  whenever  tlie  graphics  service  runs  as  a  separate  process 
from  die  application.  Resides  the  time  for  the  actual  message  passing  and  context  switching,  the 
operations  must  be  encoded  into  and  dccixlcd  from  the  message. 

•  Data  movement.  This  is  the  cost  of  copying  information  from  the  address  space  of  the  application 
to  the  server,  incurred  whenever  the  server  is  not  linked  into  each  application. 

Comparing  line  4  to  line  5  indicates  a  27%  performance  difference  when  using  the  VGTS  instead  of 
W.  Although  some  of  this  may  be  due  to  SDK  interpretation  overhead,  most  is  due  to  tlic  following  VGTS 
features: 

•  Client  stream  interface.  The  prototype  interface  library  encodes  all  graphics  operations  into  a 
stream  of  bytes,,  and  uses  the  standard  V  1/0  protocol.  Ihis  allows  for  1/0  redirection,  even 
among  machines  with  different  byte  orders. 

•  Server  stream  interface.  The  prototype  server  imp]cmcntatjon  decodes  the  graphics  operations 
from  the  byte  stream  and  calls  appropriate  internal  functions. 

•  Error  checking.  Tlie  VGTS  attempts  to  do  most  error  checking,  such  as  verifying  that  table 
indices  are  within  their  proper  bounds,  at  SDF  creation  time,  so  subsequent  redraws  will  perform 
at  full  hardware  speed, 

•  Memory  allocation.  Memory  must  be  allocated  to  tlie  SDF  display  records  for  each  new  objecL’ 

Once  the  memory  is  obtained  from  the  system,  this  involves  only  a  simple  pointer  movement 
down  the  free  list 

•  SDF  Saving.  The  actual  overhead  for  saving  die  display  record  involves  storing  the  coordinates 
and  attrioutes  (usually  insignificant)  and  calculating  the  extent  of  tlie  currently  open  symbol. 

Despite  these  costs,  the  VGT'S  distributed  rate  (line  3)  is  higher  than  W  (line  4).  ITiis  shows  that  a  significant 
amount  of  the  overhead  is  incurred  on  die  client  which  results  in  a  benefit  from  concurrency.  It  is,  in  fact 
standard  protocols  such  as  V  I/O  and  the  byte  stream  concept  diat  facilitate  distribudon. 

Note  that  almost  all  of  these  costs  must  still  be  incurred  even  if  SDFs  were  not  used  to  retain  the  graphics 
information:  die  only  saving  would  be  the  few  microseconds  to  store  into  die  display  record.  Of  course,  some 
overheads  could  be  avoided  by  using  only  one  process,  one  address  space,  screen  coordinates,  etc.  but  the 
resulting  system  would  not  have  the  advantages  described  in  die  last  chapter. 

Finally,  comparisons  of  application«-scrccn  throughput  show  the  VG'l'S  at  its  worst  case,  since  they  do  not 
take  advantage  of  the  display  file.  l-!ven  dioiigh  the  initial  picture  sometimes  takes  longer  to  appear  when 
using  die  VG  I  S.  once  it  is  defined  it  can  be  drawn  very  quickly,  l-’or  example,  in  response  to  screen 
management  tiperations.  any  W-like  system  would  require  the  application  to  redisplay  its  contents  at  the  300 
vectors  per  second  rate,  while  the  VG'l'S  would  redisplay  at  430  vectors  per  second,  a  43%  performance 
advantage. 

A  simple  qualitative  measure  of  text  performance  is  how  die  VG'l'S  compares  to  standard  RS-232  9600 
baud  terminals,  which  generate  about  940  characters  per  second.  For  example,  consider  a  typical  page 
forward  command  in  a  screen  editor  which  changes  about  1000  chariKters.  On  a  9600  baud  RS-232 
connection  diis  would  take  about  one  second.  With  die  VG'l'S  it  takes  about  a  fiRh  of  a  second,  which  is  fast 
enough  to  seem  instantaneous  to  most  users. 

1'he  remainder  of  this  chapter  will  attempt  to  show  the  effect  of  varying  difTcrent  parameters,  and  evaluate 
the  effects  to  the  limited  extent  possible  in  the  configurations  available.  'I'hcsc  parameters  include: 
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•  speed  of  the  workstation  and  graphics  device 

•  speed  of  the  remote  host  (if  any) 

•  speed  of  the  network 

•  choice  and  implementation  of  transport  protocol 

•  level  at  which  information  is  communicated,  including  characteristics  of  the  virtual  graphics 
terminal  protocol 

6.4  Internal  Factors 

For  many  application  programs  with  large  proccisor  demands,  the  importance  of  the  speed  of  the  graphics 
can  be  insignificant  compared  to  the  importance  of  the  speed  of  tlie  application.  These  programs  arc  ideally 
suited  to  the  VG'l'S  architecture  since  the  application  can  be  run  on  a  larger,  specialised,  high-performance 
processor  instead  of  the  workstation,  'flius,  the  major  concern  is  when  the  frequency  of  interaction  is  high. 

Even  though  the  VGTS  was  designed  for  efficient  partitioned  operation,  it  is  still  good  at  local  operation. 
As  we  shall  sec,  the  most  important  factors  affccling  tlie  performance  of  the  VG’l'S  are  the  same  as  those 
affecting  most  other  programs.  This  might  be  considered  as  unfortunately  mundane,  but  it  means  that  the 
VG'fS  can  take  advantage  of  the  many  well-known  techniques  for  making  typical  programs  run  faster;  there 
arc  no  inherent  performance  reasons  to  prevent  the  use  of  VGTS  concepts. 


6.4.1  Effects  of  Graphics  Package 

•  » 

One  of  tlicsc  important  factors  that  is  often  overlooked,  is  that  for  any  program,  most  of  the  time  is  spent  in 
a  small  part  of  the  code.  In  the  case  of  die  graphics  benchmarks,  much  of  the  execution  time  was  spent  in  the 
vector  or  rcchinglc  drawing  function.  1hc  llrcscnham  algorithm,  which  is  usually  die  fastest,  was  used  to 
draw  vcctois  [20).  However,  even  a  straightforward  implementation  of  die  fastest  algorithm  was  much  slower 
than  an  implementation  using  clever  coding  of  the  inner  limps  of  the  llrcscnham  algorithm. 

In  the  clever  implementation,  the  vector  drawing  function  compiles  a  custom-made  inner  loop  for  each 
vector.  This  Uikcs  a  little  more  time  to  set  up  for  each  vector,  but  diis  initial  time  is  kept  small  by  using  tabic 
look-ups.  As  seen  in  Table  6-3,  using  compiled  vectors  instead  of  sU'aightforward  coding  yielded  a  200% 
improvement  in  vectors  per  second  on  the  draw  rate.  However,  using  die  VG'l'S  introduced  some  overhead 
on  the  drawing  times  since  it  is  interpreting  a  structured  display  file.  Table  6-3  showed  diat  the  SDF 
overhead  is  very  small  compared  to  the  large  improvement  from  compiled  vectors. 

Unfortunately,  the  speedup  from  chosing  a  good  algoridmi  and  optimizing  its  inner  loop  is  good  for  only  a 
one-time  increase  in  performance.  Once  the  best  algorithm  is  found  and  its  inner  loops  arc  hand-optimized, 
more  work  will  not  rcsull  in  more  pcrl'ormance  improvements.  On  the  other  hand,  the  cost  of  carefully 
recoding  one  module  or  writing  a  lew  lines  of  assembly  code  is  usually  small,  so  die  return  on  the  investment 
is  good  up  to  a  point. 


6.4.2  Effects  of  Processor  Speed 

Another  fairly  obvious  fact  diat  is  often  overlooked  is  that  the  speed  of  an  application  is  directly  related  to 
the  speed  of  the  pnxrcssor  on  which  it  runs.  Table  6-4  compares  the  performance  of  workstations  that  have 
two  different  basic  clock  rates,  but  arc  similar  in  most  other  respects.  Use  of  10  MHz  Sun  workstitions 
instead  of  8  MHz  workstations  yielded  up  to  22%  improvement.  I’hc  principal  reason  diat  the  increase  from 
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8Mhz  to  lOMhz  68000  processors  did  not  produce  a  25%  increase  in  tlie  performance  was  that  tlie  lOMHz 
design  required  polling  of  the  keyboard  and  mouse.  Similarly,  executing  the  application  on  a  Vax-11/780 
instead  of  a  Vax-11/750  yields  up  to  50%  improvement  (see  Table  6*5). 


Vectors/second 


Configuration 

IKP 

PUP 

R-IP 

10. 780,  batch 

210 

190 

130 

no 

92 

8. 780,  batch 

180 

150 

no 

99 

88 

Characters/second 

10, 780,  text 

7700 

4300 

1600 

4300 

1900 

8, 780,  text 

6700 

3200 

1400 

3600 

1800 

Tabic  6-4:  Effect  of  workstation  speed 

Two  of  the  more  surprising  results  relate  to  the  benefits  of  distributed  computing.  First,  applications  can  be 
expected  to  run  7&s/er  when  distributed  between  a  Vax-780  and  a  Sun  workstation  than  when  run  locally  (see 
Table  6-6).  Even  if  eonstruction  rates  are  lower  in  the  disyibuted  case,  the  concurrency  from  the  use  of  two 
processors  resulted  in  higher  rates  for  both  batch  and  incremental  display.  Second,  some  applications  execute 
faster  using  a  Vax-785  on  the  ARPANrr  than  using  a  Vax-750  on  the  IcKal  net  (sec  Table  6-7).  Since  the 
ARPANirr  is  substantially  slower  than  the  Ethernet  and  network  communication  in  general  u  slower  than  local 
communication,  the  conclusion  is  that  CPU  speed  is  the  dominant  factor  in  this  instance. 


Vectors/second 


Configuration 

IKP 

PUP 

H9Ta 

10, 780,  construction 

510 

210 

170 

10, 750,  construction 

340 

130 

no 

Characters/second 

10. 780,  text 

4300 

1600 

4300 

10, 750,  text 

4100 

1400 

2300 

Table  6-5:  Effect  of  remote  host  speed 

Note  that  Table  6-4  and  6-6  contain  batch  rates,  to  emphasize  overall  performance.  Table  6-5,  on  the  other 
hand,  contains  construction  rates,  to  emphasize  the  performance  of  the  processor  executing  the  application. 
However,  regardless  of  where  the  application  executes,  the  workstation  is  always  required  to  do  some  work, 
namely,  to  mainUiin  and  display  the  graphical  objects.  'ITicrcforc,  performance  is  more  sensitive  to 
workstation  speed  than  to  remote  processor  speed.  For  example:  whereas  a  25%  increase  in  workstation 
speed  results  in  almost  linear  speed-up.  a  100%  increase  in  Vax  speed  results  in  at  most  50%  speed-up  as  seen 
in  Tables  6-4  and  6-5.  Note  tliat  Tables  6-4  and  6-5  were  constructed  with  early  versions  of  tlie  protocols; 
later  changes  to  the  protocols  increased  tlie  sensitivity  of  II’  to  server  host  speed,  but  dareased  the  sensitivity 
of  I  Kl’ and  I’UP. 

Vectors/second 

Configuration _ 1-W41 _ ^ 

10. 780,  batch  220  380 

10. 780,  incremental  62  92 

Table  6-6:  SuN  vs.  Ethernet-based  780 

One  might  conclude  from  these  measurements  that  tlicre  is  little  reason  to  distribute  applications,  since 
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Vectors/second 


Configuration 

K-IP 

A-IP 

10, 785,  construction 

160 

10, 750,  construction 

130 

10, 785,  batch 

140 

10, 750,  batch 

125 

Table  6-7:  ARPANirr-based  785  vs.  Ethernet-based  750 

batch  rates  arc  comparable  between  local  and  remote  applications.  Performance  should  be  improved  as  two 
processors  arc  used.  However,  our  benchmarks  make  no  significant  computational  or  database  demands  that 
would  take  advantage  of  faster  hosts.  Moreover,  as  mentioned  in  Section  1.2.2,  some  applications  simply 
cannot  run  on  the  workstation,  due  to  memory  or  language  requiremenLs,  for  example.  Non-graphical 
applications  can  be  expected  to  depend  more  on  disk  or  operating  system  performance,  softening  the  impact 
of  proces-sor  speed.  On  the  other  hand,  compute-bound  applications,  including  any  that  use  floating  point, 
arc  impacted  more  heavily  by  host  processor  speed. 


6.4.3  Effects  of  Graphics  Hardware 

Table  6-8  gives  the  effect  of  two  measured  frame  buffers.  The  first  line  in  the  table  refers  to  the  original 
frame  bufl'er  which  simplified  graphics  primitives  by  providing  bit-shifting  hardware.  'Hie  second  line  refers 
to  the  frame  buffer  in  which  display  memory  is  byte-addressed  like  all  other  memory.  The  second  frame 
buffer  is  about  30%  slower  on  vector  drawing  than  the  original  frame  buffer.  However,  creation  is  faster  on 
the  Sun-2,  due  to  a  slightly  different  I/O  architecture.  Although  the  Sun-2  is  still  about  15%  slower  for  the 
total  local  batch  rate,  remote  batch  rates  arc  sometimes  higher  due  to  CPU  saturation. 


Vcctors/sccond 


Conficuration 

Draw 

Create 

Batch 

E-IP 

Sun-1, 750 

430 

440 

220 

220 

Sun-2, 750 

290 

470 

180 

170 

Table  6-8:  liffcct  of  frame  buffer 


6.5  Protocol  Factors 

The  nature  of  the  applications  and  of  tlic  information  they  communicate  among  llicir  distributed  parts 
make  the  network  behave  differently  from  what  might  commonly  be  expected.  I'hc  use  of  high-level  graphics 
protocols  reduces  tlic  degradation  that  is  experienced  between  dill'erenl  bandwidth  networks.  ’ITiis  can 
influence  the  choice  of  network  proUKols  since  the  pcrrormance  penally  ofacccssing  a  high-performance  host 
over  a  long-haul  internetwork  instead  of  a  less  powerful  host  located  on  a  local  network  may  he  outweighed 
by  titc  difl'crence  in  host  capabilities. 

From  another  point  of  view,  the  higher-level  protocols  tend  to  increase  the  CPU  cost  of  fast 
communication.  'Ihis  may  be  an  advantage,  due  to  the  decreasing  costs  of  CPUs  compared  to 
communication,  but  also  means  that  less  of  tlic  CPU  is  available  for  other  uisks.  In  concrete  terms,  the 
prottKols  are  “high  level"  since  they  deal  with  graphical  objects  like  lines  and  polygons  instead  of  low-level 
bitmap  operations,  and  they  hike  advantage  of  structure. 
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6.5.1  Effects  of  Structure 

As  discussed  in  Section  3.4,  the  VGTF  allows  objects  to  be  defined  in  terms  of  graphical  primitives  such  as 
vectors  or  rectangles,  or  in  terms  of  other  objects.  Once  the  objects  are  defined,  they  can  be  made  to  appear 
on  or  disappear  from  the  screen  with  short  commands  of  only  a  few  bytes.  The  performance  advantages  of 
retaining  the  display  files  on  a  dedicated  workstation,  introduced  in  Section  5.1,  have  been  known  for  some 
time  [88).  The  following  tests  were  performed  with  a  program  that  used  the  structuring  facilities  of  the  VGTS 
to  create  30  instances  of  a  symbol  consisting  of  26  rectangles  each. 

The  results  for  the  structure  benchmark  are  given  in  Table  6-9.  The  first  thing  to  notice  is  the  very  low  rate 
for  incremental  performance,  especially  over  long-delay  networks  like  the  Arpanet.  By  batching  and 
pipelining  the  operations,  performance  increases  by  a  factor  of  7  for  local  operations,  30  for  Ethernet 
operations,  and  40  for  ARPANET  operations.  Using  structure  instead  of  an  unstructured  list  of  primitive  items 
increases  performance  again  by  factors  of  3  to  4  for  both  local  and  remote  operations. 


Rectanglcs/sccond 


;!onfieuratii 


10,  750,  incremental 

41 

5 

2 

10. 750,  pipelined  incremental 

61 

66 

36 

10,  750,  batch  unstructured 

310 

180 

81 

10,  750,  batch  structured 

1070 

670 

370 

Tabic  6-9:  Effect  of  structure 

• 

Some  other  interesting  observations  can  be  made  from  Table  6-9  that  reflect  the  value  of  batching  and 
structure.  First,  the  time  to  define  and  display  the  picture  for  a  local  application  was  about  1  millisecond  per 
item.  Ihis  is  roughly  die  time  to  perform  a  local  Send  -  Receive  -  Reply  sequence  in  tlic  V  kernel  [31),  so  any 
protocol  that  uses  a  mcs.sagc  transaction  for  each  item  will  be  slower.  Secondly,  it  is  faster  to  run  this 
benchmark  over  the  Arpanet  and  use  structure  than  it  is  to  run  the  same  program  locally  and  use 
incremental  or  unstructured  display.  'Ilic  latter  is  comparable  to  traditional  graphics  systems.  It  is  also  faster 
to  run  the  program  across  the  Ethernet  and  use  structure  than  it  is  to  run  the  program  locally,  even  with 
batching. 

Structure  introduces  a  slight  amount  of  overhead,  since  the  VGTS  must  trace  through  the  symbol  data 
structure.  However,  in  this  benchmark  the  structure  interpretation  introduced  an  overhead  of  about  20 
milliseconds  out  of  about  900,  or  less  than  3%  of  tlie  local  draw  time.  I  bus  there  is  little  perfonnance 
advantage  to  use  a  segmented  display  file  instead  of  an  arbitrarily  structured  one.  By  using  a  linear  list  instead 
of  a  linked  list,  display  reciirds  could  be  16  bytes  instead  of  20,  or  a  20%  savings  in  memory.  Unfortunately 
this  would  make  insertion  and  deletion  much  more  difficult  Moreover,  die  SDF  representation  is  already 
quite  concise,  as  will  be  shown  in  Section  6.5.3. 

6.5.2  Effects  of  Batching  and  Pipelining 

Comparing  the  batch  and  incremental  rates  in  Table  6-1  as  well  as  'fable  6-9,  shows  the  importance  of 
batching.  The  original  implementation  of  the  VG  TP  employed  a  return  value  for  c.ich  operation.  In  tlic 
current  implementation  operations  are  batched  so  that  values  are  returned  only  after  an  entire  sequence  of 
operations  (such  as  all  changes  to  a  given  symbol)  have  been  performed.  'Ibis  change  redueed  network  delays 
substantially,  yielding  perfonnance  improvements  of  up  to  factors  of  30! 

Ibc  first  two  lines  of  Table  6-9  give  tlie  effect  of  another  important  change  to  the  VGTP.  By  removing  the 
return  values  Ironi  the  LdUSynibot  and  lindSymM  operations,  even  incremental  operations  could  be 
pipelined,  resulting  in  much  more  concurrency  than  the  “stop-and-wait"  protocol  resulting  from  return  values 
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on  each  transaction.  The  reduced  message  traffic  caused  an  increase  of  50%  for  local  operations,  and  increases 
of  factors  of  10  to  15  for  remote  operations.  In  fact,  remote  incremental  operations  arc  almost  always  faster 
than  local  incremental  operations  due  to  this  concurrency. 


6.5.3  Comparison  to  Bitmap  Protocols 

Many  approaches  to  graphics  within  a  distributed  system  use  protocols  based  on  bitmap  manipulation. 
Unfortunately,  bitmap  protocols  can  be  inefficient  in  both  their  bandwidth  and  memory  utilization.  By 
reducing  the  length  of  the  descriptions  of  graphical  objects,  they  arc  made  independent  of  the  structure  of  the 
bitmap  as  well  as  being  smaller  in  both  transmission  and  storage. 

The  advantages  of  the  SDF  for  memory  usage  arc  indicated  in  Table  6-10.  In  the  vector  benchmark,  the 
SDF  represented  the  fully-connected  polygon  with  20  bytes  per  item,  or  12,600  bytes.  1’his  compares  to  the 
800  by  800  bitmap  area,  which  would  take  80,000  bytes.  In  practice,  most  pictures  arc  even  less  dense  than 
the  fully-connected  polygon,  so  tlic  advantage  would  be  even  greater.  In  particular,  the  SDF  approach  has 
the  advantage  as  long  as  there  arc  more  tiiat  20  bytes  of  bitmap  space  for  each  item  in  the  SDF.  Tlie  rectangle 
benchmark  shows  that  even  without  using  structure,  a  factor  of  about  two  in  memory  savings  is  possible. 
Using  structure,  the  900  bytes  used  by  the  SDF  is  a  factor  of  37  less  than  the  space  for  the  bitmap.  Similar 
large  improvement  factors  in  network  bandwidth  requirements  will  be  discussed  in  Section  6.6. 


Bytes  of  memory  used 


Benchmark 

SDF 

Bitmao 

vector 

12,600 

80,000 

rectangle,  unstructured 

15,600 

34,000 

rectangle,  structured 

900 

34,000 

Tabic  6-10:  Effect  of  SDF  on  memory  usage 


6.5.4  Effects  of  Transport  Protocols  and  Their  Implementations 

As  noted  for  'fable  6-5,  three  different  transport  protocols  were  used,  with  significantly  different 
pcrforiTOincc  results.  Ilic  V-system  supporLs  both  a  kKal  protocol  and  two  general  intcr-nctwtirk  byte-stream 
protocols.  I'hc  liKal  protiKol  provides  an  interprocess  communications  facility  between  V-system  prixrcsscs. 
The  two  general  protocols  arc  the  Xerox  I’UP  family  implemented  through  llie  R  TIVllSI*  level,  and  tlie  Area 
Internet  protocol  family  implemented  through  the  TCP  level.  User  I'l'i  Nl'l'  programs  exist  on  top  of  both, 
fhe  network  configurations  were  illustrated  in  Figure  6-2. 

Unfortunately  it  is  very  hard  to  compare  only  the  effect  of  protocol  design,  because  of  many 
implementation  issues  that  vary  between  tlie  protwols.  For  example,  the  implementation  of  PUP  BSP  did 
not  use  any  of  tlie  windowing  features  available  in  the  protwr)!.  resulting  in  much  lower  pciTormance  than  the 
IP.  More  iniporlanl.  ihe  packet  size  used  in  the  IKP  impicinenlation  was  1024  bylcs,  while  both  PUP  and  IP 
used  packets  of  UK)  or  200  bylcs.  On  the  other  hand,  the  incremental  rales  for  the  IKP  experiments  were  very 
p(M)r,  due  to  tlie  fact  dial  a  Unix  server  process  was  polling  every  few  seconds  for  output  from  a  pipe,  while 
the  other  proUxrols  were  interrupt  drivcn.^l'hus  the  implementation  of  tlie  proUx;ol  may  have  a  greater  effect 
that  any  properties  inherent  in  the  protocol  itself. 

Fortunately  we  were  able  to  experiment  with  different  implementations  of  the  same  prot(x:ol.  During  tlie 
course  of  our  experiments,  there  were  two  major  implcmcnUilions  of  the  Area  Internet  Protocol  available  for 


I'hc  Unix  V-server  could  be  modincd  in  4.2  (o  use  (he  se1  ec  t  system  cull  |68].  which  would  eliminate  this  delay. 
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Vax/Unix  systems.  'Ilic  first  was  done  by  Holt,  Ueranek  and  Newman  (BBN)  and  was  for  the  4.1  version  of 
Unix  [61].  'fhe  second  was  done  by  the  University  of  California  at  Berkeley  for  the  4.2  version  of  Unix  [68]. 
The  relative  performances  of  these  two  implementations  of  the  same  protocol  are  given  in  table  6-11.  The  4.2 
implementation  is  14%  faster  for  batch  construction  and  display  rates,  'fhe  difference  in  peak  throughput 
rates  is  even  more  significant,  but  even  this  higher  rate  is  several  orders  of  magnitude  below  the  actual 
bandwidth  of  the  network.  Possible  reasons  for  this  will  be  discussed  in  the  next  section. 

Vcctors/sccond 


Configuration 

4.2 

IP/TCP 

4.1 

IP/TCP 

10, 750,  construction 

140 

no 

10. 750.  batch 

93 

81 

10. 750,  incremental 

7.8 

4.8 

Tabic  6-1 1:  F.ffect  of  TCP  implementation 

Table  6-12  indicates  the  effect  of  changing  the  relative  priorities  of  the  application  program  or  the  I'ni.NET 
server  program.  This  test  was  done  using  the  PUP  protocol  on  a  local  10  Mbit/sccond  KtherncL  'Fhe  first 
column  gives  the  results  for  normal  operation.  For  the  second  column,  the  operating  system  gave  priority  to 
the  Tn.NEr  server  p-mgram.  Batch  performance  actually  decreased,  since  more  network  packets  were  sent 
For  the  tliird  column,  both  the  application  and  the  Telnet  server  were  given  priority,  which  increased  both 
the  batch  and  incremental  rates.  However,  as  shown  in  the  last  column,  the  best  performance  was  obtained  by 
giving  priority  to  the  application. 


Vectors/second 

Telser  & 

Configuration _ Normal _ Telser  Application  Application 

10. 750,  batch  170  160  190  200 

10. 750,  incremental  47  48  58  58 

Tabic  6-12:  F-ficct  of  Process  Priorities 

Another  interesting  comparison  is  between  remote  execution  on  a  timesharing  host  and  execution  on 
another  workstation.  Table  6-13  displays  this  comparison.  Hie  constniction  rate  is  about  the  s;imc  on  the 
Vax/Unix  system  and  on  the  V-System.  The  incremental  rates  on  tlic  Vax/Unix  impIcmcnLition  arc  very 
poor  without  pipelining,  due  to  the  high  delay.  Note,  however,  tliat  the  toUrl  batch  rate  and  the  pipelined 
incremental  rate  arc  much  higher  on  the  Vax  than  on  another  workstation.  This  is  due  to  tlic  fact  that  there  is 
actually  little  concurrency  in  the  remote  workstation  case,  due  to  the  synchronous  Vikp  mcs.sagcs.  Much 
better  performance  could  be  obtained  by  replying  to  the  message  before  it  is  proccs.scd.  instead  of  after  the 
operations  arc  performed. 


Configuration 

Vectors/second 
SUN  VAX 

IKP  IKP 

10. 750.  construction 

380 

380 

10. 750,  batch 

190 

350 

10. 750.  incremental 

29 

4.6 

10. 750,  pipelined  incremental 

44 

81 

Tabic  6-13:  Hffccl  of IKP  implementation 
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6.6  Network  Factors 

ITic  use  of  networks  implies  both  limitations  in  bandwidth  and  increased  delays.  All  of  the  above  factors 
(and  our  design  and  implementation)  combine  to  render  the  actual  network  bandwidth  insignificant.  Table 
6-14  shows  tiiat  although  a  3  Mbit/second  Ethernet  is  about  60  times  faster  than  the  56  Kbit/second  links 
used  in  the  ARPANtn,  using  a  backend  host  on  the  local  network  yields  less  tlian  a  50%  performance 
improvement  over  using  a  backend  host  on  the  ARPANirr*.  Moreover,  there  was  very  little  measurable 
performance  difference  between  using  the  3  Mbit/second  experimental  Kthernet  ratlier  than  10  Mbit/second 
standard  Hthernet  [44].  I'he  column  labeled  ElO-lP  refers  to  standard  10  Mbit/second  Htliernet.  Although 
the  Kthernet  is  about  180  times  faster  than  die  links  used  in  the  Arpani-t,  die  Kthernet  construction  rates  are 
less  dian  twice  the  ARPANirr  rate.  In  fact,  most  of  die  dilTercncc  in  the  total  batch  rate  is  due  to  the  delay  of 
the  AKPAM-n  and  intervening  gateway,  not  any  bandwidth  restriction.  Karlicr  implementations  of  the 
protocols  had  even  less  of  difference. 

Vcctors/sccond 

Con  fieu  ration _ K-IP  KIO-IP _ A-IP 

10, 750  4.2,  construction  220  230  130 

10, 750  4.2,  batch  210  220  120 

Tabic  6- 1 4:  Kffect  of  network  bandwidth 

These  results  can  be  attributed  primarily  to  the  level  of  communication  as  discussed  in  section  6.5.1,  and  the 
conclusion  that  processor  speed  is  the  usual  bottleneck.  This  is  consistent  with  other  measurements  of 
Hthernet  performance  [120]  diat  show  very  low  utili/.ation  of  the  available  bandwidth  of  the  Kthernet,  and 
comparalively  long  delays  on  the  Arpa  Network.  Thus,  these  systems  rarely  approach  the  limits  described  in 
analytical  studies  that  concentrate  on  performance  under  heavy  loads  [145].  In  fact,  these  protocols  can  be 
u.scd  on  very  low-bandwidth  communication  links. 

Kach  AJdhem  call  sends  20  bytes  of  data,  so  a  construction  rate  of  230  items  per  second  (the  Ethernet  load 
given  in  Table  6-14)  corresponds  to  only  4600  bytes  per  second,  or  about  40  Kbits/second,  about  0.4%  of  the 
Kthernet  s  bandwidth.  Due  to  tlie  small  amount  of  data,  graphics  could  even  be  possible  over  standard  speed 
telephone  lines.  For  example,  at  1200  biLs/sccond.  a  peak  rate  of  7.5  ilcms/sccond  should  be  possible.  To  test 
tliis,  die  experiment  was  run  successfully  on  a  workstation  over  a  1200  bits/second  telephone  link.  Several 
other  rates  were  tested  using  point-to-point  l<S-232  connections  at  various  speeds,  with  the  results  given  in 
Table  6-15. 


Items/second 


Conficuration 

1200 

2400 

4800 

9600 

H-IP 

10.  750  4.2.  construction 

7.4 

14 

26 

54 

166 

10. 750  4.2,  batch 

6.2 

12 

23 

46 

131 

10.  750  4.2,  structure 

84 

142 

230 

320 

380 

l  ablc  6-15:  l•,(Tcct  of  point-to-p«)inl  communication  rates 

For  the  structure  benchmark,  even  at  1200  biLs/second.  the  measured  creation  rate  was  7.4  itcms/sccond. 
very  close  to  the  maximum  7.5  calculated  above.  This  rate  is  slightly  less  than  linear  in  relation  to  die 
bandwidth,  indicating  that  even  at  low  speeds  the  CPU  can  be  a  factor.  Moreover,  the  total  rate  when  using 
structure  was  84  items/second  at  1200  bits/second,  which  is  twice  as  fast  as  running  tiic  program  locally  with 
incremental  drawing  (the  first  entry  in  Table  6-9).  Structure  and  lack  of  significant  delays  also  makes  this 


In  fact.  Ihc  cxpcrimciiial  lilhcrncl  is  really  about  2  93  Mbil/sccond 
the  56  Kbit/sccond  of  the  Arpanut  link! 


The  dilTcrenci  between  thus  and  3  Mbit/sccond  is  greater  than 
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Structure  rate  faster  than  the  batch  rate  for  the  Arpanet  (the  last  entry  in  Table  6-9).  Significant  delays  can 
even  be  seen  in  the  local  Ethernet  IP  results,  as  given  in  tlie  last  column  of  Table  6-15.  'llie  9600  bits/sccond 
structure  rate  is  only  about  15%  slower  than  using  Ethernet,  even  though  Ethernet  has  a  raw  bandwidth  a 
thousand  times  greater. 


6.7  Human  Factors 

The  actual  VGTS  could  be  instrumented  to  take  data  during  production  use.  'Phis  information  would 
record  the  frequency  of  operations  and  the  corresponding  response  time.  A  “user  simulator”  could  be  written 
to  simulate  a  real  user's  command  sequence,  with  suitable  randomness.  This  could  be  used  to  tunc  the 
performance  of  the  VG'fS  to  match  the  user  profiles  gathered  in  the  above  experiments.  More  elaborate 
instrumentation  results  would  be  very  interesting,  but  arc  beyond  the  scope  of  this  thesis. 


Objects 

Time 

Rate 

Bitmao 

SPF 

Maximum 

365 

1370 

266 

40K 

7.3K 

Mean 

116 

485 

234 

21K 

2.3K 

Median 

101 

430 

235 

19K 

2.0K 

Minimum  . 

33 

160 

203 

13K 

0.7K 

Table  6-16:  Instrumentation  data 


Instead,  the  illustration  editor  used  to  create  the  diagrams  used  in  this  thesis  was  instrumented  to  measure 
both  response  time  and  memory  usage.  The  detailed  measurements  arc  given  in  Table  D-4  in  Appendix  D, 
with  a  summary  given  here  in  Tabic  6-16.  This  table  gives  the  maximum,  minimum,  median,  and  mean  for 
each  value.  These  tables  list  the  number  of  items  in  each  figure,  the  time  for  display  in  milliseconds,  the 
resulting  rate  (including  both  creation  and  display)  in  items  per  second,  die  memory  tliat  would  be  needed  to 
store  the  bitmap  (in  thousands  of  bytes),  and  and  the  memory  used  in  the  SDK  (also  in  thousands  of  bytes). 
The  average  times  were  under  half  a  second,  resulting  in  quite  good  response,  'fhe  memory  savings  averaged 
around  a  factor  of  ten  fur  using  an  SD1<  instead  of  a  bitmap. 


6.7.1  Levels  of  Responses 

Unlike  other  studies  which  consider  throughput  the  factor  to  be  optimized,  we  have  concentrated  on 
optimizing  response  time.  Experiments  have  shown  that  users  prefer  systems  with  low  variability  of  response 
time,  even  if  the  throughput  is  slightly  lower  [98]. 

One  natural  division  of  functions  from  a  linguistic  point  of  view  is  into  tlic  following  three  general 
categories  [151]: 

Lexical  'Ihcsc  operations  require  immediate  user  feedback,  on  the  order  of  50  milliseconds.  I'his  rate 
(20  cvcnts/sccond)  corresponds  roughly  to  an  upper  bound  on  tlic  speed  of  very  fast  typists 
(keystrokcs/sccond). 

Syntactic  Hicsc  operations  involve  a  single  syntactic  operation,  and  can  take  up  to  0.5  to  1  second. 

Semantic  Major  operations  can  take  on  the  order  of  tens  of  seconds  without  the  users  losing  their  trains 
of  thought 

Clearly  all  lexical  interactions  should  be  performed  on  the  workstation.  In  fact  the  VGI'S  line  editing  and 
cursor  tracking  account  for  most  of  tlicsc  lexical  actions.  Syntactic  actions  include  screen  management  and 
selection  feedback.  In  the  VG  I'S  tlicsc  operations  arc  typically  performed  outside  tlic  service,  but  in 
programs  residing  on  the  workstation.  Syntactic  responses  can  even  be  done  across  tlic  network  if  tlic  load  on 
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the  remote  host  is  not  very  high.  Larger*scale  semantic  operations,  like  loading  and  running  large  programs, 
searching  central  databases,  or  compilation,  are  typically  done  on  remote  server  hosts  or  distributed  between  a 
server  host  and  the  workstadon. 


6.7.2  Keystroke  Data 

Many  studies  have  been  done  for  text  editors  to  determine  the  common  operations  [26, 57].  These  studies 
can  be  extended  to  graphics,  but  arc  also  valuable  in  their  own  right  since  a  large  part  of  any  user’s  interaction 
is  still  textual.  'ITic  main  conclusion  of  these  studies  is  tliat  the  majority  of  the  users’  time  is  spent  doing  very 
simple  repetitive  tasks.  I'hus  we  concentrated  on  making  these  few  simple  tasks  faster  by  taking  advantage  of 
the  power  of  the  local  workstation. 

6.8  Discussion  of  Results 

To  summarize  our  findings,  the  primary  factors  affecting  performance  of  our  distributed  graphics 
applications  are.  in  approximate  order  of  importance: 

1.  Speed  of  the  workstation. 

2.  Speed  of  the  remote  host,  if  any. 

3.  Level  of  communication,  as  determined  by  the  virtual  graphics  terminal  protocol. 

4.  Bandwidth  of  the  networks  employed. 

Essentially  the  same  observations  hold  for  text.  Note  that  these  observations  relate  to  the  degree  of 
performance  improvement  relative  to  the  degree  of  change  in  the  indicated  parameters.  Thus,  a  50% 
performance  improvement  due  to  a  200%  increase  in  processor  speed  could  be  considered  relatively  greater 
than  a  300%  improvement  in  performance  due  to  a  6000%  increase  in  network  speed.  ITie  importance  of 
CPU  speed  and  amortizing  communication  costs  over  large  buffers  was  a  major  conclusion  of  one  of  the  few 
other  similar  studies  [85]. 

It  is  relatively  ea.sy  to  rate  the  sensitivity  to  hardware  factors.  Software  factors  arc  another  matter;  it  is  easy 
to  measure  die  absolute  performance  improvement  resulting  from  a  change  in  software,  but  quite  diftlcult  to 
measure  die  cost  of  the  software  change.  Nevertheless,  certain  conclusions  will  be  drawn  based  on  available 
information.  Also  note  that  there  arc  limits  beyond  which  changing  one  factor  will  not  alTcct  pcrfonnance; 
for  example,  a  CPU-bound  application  running  on  a  remote  host  will  be  little  affected  by  an  increase  in 
worksUition  speed. 

CPU  speed  rates  at  the  top  of  the  list  simply  because  desired  speed-ups  can  be  achieved  almost  indefinitely 
by  siibstiliiling  more  powerful  workstations  and  backend  hosts.  Continuous  improvement  is  mU  possible  with 
network  proUKoIs.  IKP,  for  example,  provides  as  gmul  performance  on  the  UK'al  net  as  can  be  achieved. 
Another  way  of  saying  diis  is  diat  network  prolocrds  arc  limited  by  die  available  hardware,  and  die  most 
important  piece  of  hardware  is  the  CPU. 


6.8.1  Hardware  Factors 

As  worksUitions  become  more  powerful,  one  might  think  that  offloading  functions  from  hosts  to  the 
workstation  means  that  slower  backend  hosts  can  be  used.  In  reality,  faster  hosts  arc  required  to  keep  up  with 
the  increased  demands  of  the  workstitions.  On  the  other  hand,  one  might  think  that  as  networks  become 
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faster,  communication  is  cheap.  Unfortunately,  network  interfaces  have  not  kept  pace  with  bandwidth,  so 
that  many  network  operations  remain  CPU-bound.  In  both  eases,  the  offloading  and  increased  bandwidth 
may  allow  more  users  to  share  the  same  resource,  but  do  not  increase  the  performance  for  individual  users. 
Hencc,y&5/er  hosts  arc  needed,  not  slower  ones. 

Similarly,  network  controllers  arc  now  being  marketed  with  microprocessors  that  are  intended  to  offload 
taskj  from  the  main  processor.  Our  experience  has  been  that  such  controllers  arc  usually  slower,  not  faster, 
than  simpler  and  cheaper  controllers  that  perform  fewer  Ainctions  but  use  fixed  logic  at  a  higher  speed. 

With  respect  to  network  bandwidth,  sensitivity  is  directly  related  to  communication  requirements. 
Communications  requirements  arc  inversely  related  to  the  frequency  of  communication  and  the  amount  of 
information  U'ausmittcd.  both  of  which  arc  reduced  by  the  techniques  discussed  above.  Therefore,  the 
remarkable  insensitivity  of  our  applications  to  network  bandwidth  implies  that  they  arc  quite  sensitive  to  the 
“lever’  of  communication. 


6.8.2  Software  Factors 

This  high  level  of  communication  is  due  to  the  Virtual  Graphics  Terminal  Protocol  design.  In  particular, 
the  ability  to  batch  many  operations  into  a  single  update  using  a  small  number  of  bytes  provided  large 
increases  in  performance. 

It  is  hard  to  make  direct  comparisons  about  network  protocols  independent  of  their  implementations.  For 
example,  a  protocol  inside  the  kernel  of  an  operating  system  is  usually  more  responsive  than  if  it  is 
implemented  on  top  of  the  kernel.  Of  course,  a  processor  runs  at  the  same  speed  both  in  kernel  and  user 
state.  'Ihc  increased  responsiveness  comes  with  the  cost  of  increasing  the  size  of  the  (usually  always  resident) 
kernel  and  the  related  difllcultics  of  debugging  at  lower  levels. 

In  our  particular  ease,  despite  the  fact  tliat  the  PUP  protocols  arc  simpler  than  the  Arpa  Internet  protocols, 
Arpa  Internet-based  Tiu.nlt  connections  can  sometimes  run  about  twice  as  fast  as  PUP-based  ones.  This  is 
attributed  primarily  to  the  fact  that  PUP  is  implemented  as  an  application  outside  the  Unix  kernel  whereas 
tlic  Arpa  Internet  protocols  arc  implemented  inside  the  kernel. 

For  very  time-critical  functions  such  as  network  communications,  mcs.sagcs  and  process  context  switches  arc 
expensive  even  in  systems  designed  to  provide  very  fast  mcsswigc  passing  and  light-weight  processes.  'I’he 
interested  reader  should  refer  to  [82]  for  a  more  dcUiilcd  analysis  of  the  networking  issues  which  arc  not  of 
direct  concern  of  this  thesis. 


6.8.3  Fitting  the  Model 

'Ihc  experiments  given  in  this  chapter  give  some  estimates  of  the  times  used  in  tlic  models  of  Section  5.3. 
I'or  cx.impic,  peak  pipelined  incremental  rates  arc  about  W)  inlcnictions  per  second,  or  +  *  Nciln 

about  l/()(Hh  second.  If  this  is  less  than  the  swapping  limes  +  I  swiiHim  workslation/host 

split  will  be  faster,  even  with  comparable  computation  times.  Most  of  today's  personal  computers  take  much 
longer  tlian  1/60  second  to  swap  an  application  out  and  back  in.  'Ihc  advanUigc  will  increase  with  more 
powerful  hosts  and  less  powerful  workstations. 

Of  course,  care  must  be  taken  when  generalizing  tJicsc  results  to  other  program.s.  Ihcsc  benchmarks  were 
intended  as  communication-intensive  limits,  since  they  only  do  graphics  and  no  real  computation.  More 
sophisticated  applications  could  be  expected  to  achieve  even  larger  speed-ups  when  distributed.  'Ihe 
insirumenuition  results  show  that  the  synthetic  benchmarks  arc  not  fundamentally  different  from  actual 
applications,  except  for  slightly  slower  rates  due  to  tlic  computation  by  tlic  application.  No  claim  is  made  that 
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these  results  allow  us  to  predict  the  performance  of  an  arbitrary  program.  On  the  other  hand,  a  protocol  that 
provided  one  hundred  items  per  second  in  our  experiments  will  probably  be  faster  that  one  that  provided  ten 
items  per  second.  More  analytical  work  needs  to  be  done  to  accurately  predict  performance,  but  these  results 
provide  a  start 
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Conclusions  and  Future  Work 

The  previous  chapters  described  the  motivation  for,  the  design,  implementation,  rationale,  and 
measurements  of  a  simple  distributed  graphics  system.  ITiis  Oiaptcr  draws  a  number  of  conclusions  from  this 
work,  and  presents  possible  extensions  for  the  future. 

7.1  Structured  Display  Files  and  Virtual  Terminals 

The  first  important  conclusion  is  that  the  structured  display  file  technique  can  be  combined  with  the  virtual 
terminal  concept,  resulting  in  an  architecture  for  distributed  graphics.  ITic  virtual  tcnninal  concept,  described 
in  Section  2.3,  provides  the  user  with  access  to  multiple  simultaneous  distributed  resources.  The  Virtual 
Graphics  Terminal  Server  mediates  between  application  programs  that  share  a  workstation  dedicated  to  a 
single  user. 

The  declarative  nature  of  structured  display  files  outlined  in  Chapter  3  reduces  communication,  and  allows 
higher-level  short  circuiting.  I'he  performance  and  decreased  memory  utilization  motivations  for  structure 
given  in  Section  5.1.1,  arc  supported  by  the  measurements  in  Section  6.5.1.  In  particular,  SDFs  can  yield  both 
higher  performance  and  lower  memory  requirements  than  traditional  graphics  systems,  'lltcse  advantages 
increase  as  pictures  become  more  structured,  and  applications  perform  more  incremental  updates.  The 
VGT’S  performs  cursor  motion,  screen  managcmenL  and  keyboard  echoing  internally  (as  described  in  Section 
5.1),  resulting  in  a  short-circuit  of  the  interactive  response  cycle  for  these  common  operations. 

7.2  User  and  Program  Interface  Separation 

The  VGTS  architecture  first  specified  only  the  application  program  interface  for  defining  and  modifying 
objects,  in  Section  3.4.  A  separate  user  interface  for  viewing  those  objects  was  then  specified  in  Section  4.4. 
'Hie  prototype  implementation  rigidly  enforced  this  distinction:  applications  could  not  inquire  the  size  of  the 
screen,  for  example,  and  adapt  themselves  accordingly. 

'llie  resulting  principle  advantage  is  absolute  device  independence  and  portability,  which  is  viuil  for  the 
reuse  of  software  with  rapidly-changing  workstation  hardware.  Concern  for  the  portability  of  the  prototype 
saved  rcimplementing  most  of  the  mcKlules  described  in  Section  4.1.1  for  new  devices,  such  as  tlie  Sun-2 
frame  buffer.  The  principle  disadvantage  is  that  customization  is  made  more  difficult.  Section  5.6  discussed 
when  customization  by  botli  users  and  programmers  is  desirable,  but  alst)  mentioned  reasons  not  to  allow 
arbitrary  customiziition. 

7.3  Transparent  Distribution 

Although  distributed  graphics  is  possible  with  the  SDK  approach,  it  still  may  not  always  be  desirable.  For 
example,  in  many  cases  running  the  benchmarks  locally  was  faster  titan  running  them  distributed. 
Unfortunately,  for  the  reasons  given  in  1.2.2,  it  is  not  always  possible  to  run  all  applications  on  the 
workstation.  Hven  if  the  necessary  resources  are  available  as  an  option  for  the  workstations,  they  arc  typically 
too  expensive  for  widespread  use.  In  other  words,  even  with  today's  advanced  hardware,  we  still  need  larger 
virtual  and  physical  memories,  and  faster  proccs.sors,  at  lower  prices. 

I’hc  proUKol  used  for  defining  objects  (the  YGIV)  was  extended  transparently  across  networks  using 
several  transport  proUKols,  described  in  Section  4.3.5.  'I'hc  same  source  program  can  be  compiled  and  linked 
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for  any  of  a  number  of  environments,  and  the  same  binary  can  be  accessed  through  three  different  transport 
protocols.  Distribution  allows  applications  to  run  on  the  best  suited  computational  resource,  and  use  multiple 
resources  to  achieve  concurrency.  'Fhese  programs  were  actually  used,  so  performance  constraints  were 
stringent.  Results  such  as  those  in  Table  6-6  show  that  distributed  operation  was  often  faster  than  local 
operation. 


7.4  Techniques  to  Improve  Performance 

'fhe  tables  in  Chapter  6  show  that  VGTS  performance  is  close  to  the  best  possible  speed.  In  the  best  case, 
the  VGTS  can  give  much  better  response  than  systems  that  do  not  retain  any  information  on  the  structure  of 
the  image,  or  allow  for  concurrent  operation.  More  instrumentation  of  applications  would  provide  useful 
information,  but  is  beyond  tlic  scope  of  this  thesis,  llic  measurements  presented  in  Chapter  6  already 
indicate  several  ways  that  performance  can  be  improved. 


7.4.1  Protocol  Design  Techniques 

Once  the  decision  to  distribute  is  made,  a  more  subjective  decision  is  what  and  when  to  distribute.  In  our 
experience,  a  few  simple  operations  and  applications  can  be  done  locally,  such  as  text  and  illustration  editors, 
and  the  resulting  average  performance  is  adequate.  The  simple  but  powerful  modeling  facilities  provided  by 
the  VGTS  allow  this  short  eircuiting. 

The  use  of  Structured  Display  Files  also  means  that  once  objects  arc  defined,  instances  of  them  can  appear 
or  disappear  with  a  very  small  amount  of  communication.  This  makes  the  protocols  very  insensitive  to 
network  bandwidth,  as  shown  in  Tables  6-14  and  6-15.  Since  delay  causes  more  restrictions  than  bandwidth, 
many  simple  operations  should  be  batched  together  rbr  each  interaction.  Return  values  should  also  be 
eliminated  whenever  possible  to  increase  concurrency  by  allowing  pipelining  to  occur.  Although  direct 
quantitative  comparisons  could  not  be  made  between  the  factors  affecting  performance,  batching  certainly  has 
a  very  important  cfFccL 


7.4.2  Softwarestructuring  Techniques 

One  interesting  rule  of  design  learned  from  the  VGTS  implementation  experience  was  to  use  software 
structuring  mechanisms  only  fur  tlie  appropriate  purpose: 

•  Use  separate  priKesscs  where  separate  threads  of  control  arc  needed,  otherwise  use  one  process. 

For  example,  the  main  part  of  the  VGTS  consists  of  many  modules  but  only  one  process. 

•  Use  teams  (complete  address  spjiccs)  for  programs  that  should  be  executed  as  a  unit  Partitioning 
the  VGTS  into  separate  teams  caused  a  great  increase  in  memory  consumption,  due  to  the 
common  library  functions. 

•  Use  modules  for  parts  of  a  program  that  can  be  separately  compiled.  A  direct  prixrcdurc  call 
interface  was  still  faster  than  otitcr  kinds  of  communication. 

Much  performance  can  be  lost  if  one  of  these  partitioning  mechanisms  is  used  improperly.  Even  on  a  system 
like  V  where  mcs<Migc  passing  is  fast,  it  is  still  slow  compared  U)  a  prtKcdurc  call.  In  particular.  Table  6-9 
shows  tliat  tlic  drawing  rate  can  approach  one  item  per  millisecond,  which  is  about  the  same  time  it  takes  to 
perform  a  mcssiigc  .Scnd/Rcccivc/Rcpiy  cycle.  Ihus  each  mcssiigc  should  cause  many  lower-level  actions 
instead  of  just  one,  reiterating  the  imporuincc  of  batching. 
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7.4.3  Internal  Performance  Tuning  Techniques 

Once  hardware  and  protocol  decisions  arc  made,  performance  can  be  improved  by  using  standard  software 
tuning  techniques  such  as  inner  loop  optimi7ation  and  increasing  buffer  sizes  and  blocking  factors.  In  fact, 
reasonable  pcrfonnancc  can  be  obtained  using  the  standard  transport  protocols  compared  in  Table  6-1, 
without  resorting  to  special-purpose  protocols  and  incurring  all  the  problems  of  being  non-standard.  On  the 
other  hand,  the  use  of  structure  and  proper  batching  and  buffering  strategics  must  be  done  at  every  level,  to 
avoid  bottlenecks. 


7.5  What  Can  be  Learned 

In  light  of  tlic  VG  TS  experience,  we  can  evaluate  some  aspects  that  were  later  determined  to  be 
unsucccssliil,  for  the  benefit  of  future  designers: 

•  llic  declarative  nature  of  the  VGTP  and  lack  of  a  simplified  interface  library  discouraged 
application  programmers  accustomed  to  more  prcKcdural  graphics  systems. 

•  Application  programs  developed  their  own  conventions  since  there  were  few  common  user- 
interface  libraries. 

•  Hneoding  graphical  information  in  the  same  stream  as  text  at  the  lowest  level  did  not  allow 
redirection  of  graphics  commands  into  a  file  or  background  graphics  programs. 

•  The  lack  of  raster  operations  in  the  programmer’s  interface  discouraged  the  use  of  the  VGTS  for 
image  processing  applications. 

•  Several  minor  dcvicc-dcpcndcncies  in  the  implementation  were  not  made  apparent  until  ports 
were  actually  attempted,  due  to  lack  of  a  wcll-spcciftcd  device  interface. 

•  The  close  coupling  of  the  view  manager  to  the  rest  of  the  VGTS  discouraged  attempts  at 
cusiomi/ation  through  user  profiles. 

Most  of  these  problems  can  be  easily  overcome  by  the  work  described  in  the  next  section. 


7.6  More  Open  Questions  t 

The  VG'l'S  effort  raised  more  questions  than  it  answered.  The  following  is  certainly  not  an  exhaustive  list, 
but  it  should  give  an  overview  of  possible  future  topics  in  this  area. 

7.6.1  Integration  withEditor 

One  useful  function  in  many  window  systems  is  the  ability  to  select  text  (or  other  data)  from  one  place  and  ] 

siuJJ'il  into  another.  Due  to  llic  simple  structure  of  text,  tliis  would  be  relatively  easy  to  add  for  clients  using 
the  byte-stream  terminal  emulation  interface.  For  advanced  graphical  objects.  SDK  and  higher-level  j 

interfaces  could  be  used.  Unfortunately  this  requires  common  data  represcnuitions  at  the  applications  level,  ; 

beyond  that  with  which  the  current  VG'l'S  prototype  is  concerned.  Since  some  performance  and  flexibility  is 
already  lost  by  enforcing  the  level  used  by  the  VG'l'S,  getting  applications  to  agree  on  even  higher  levels  could  \ 

be  quite  difficult  On  the  other  hand,  there  arc  many  potential  benefits  from  even  higher  levels  of  ;■ 

standardization. 
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7.6.2  Handling  of  Attributes 

The  VGTS  used  a  limited  number  of  attributes  for  its  primitives,  most  stored  as  a  small  integer  used  as  a 
table  index  to  get  the  actual  value.  ITiis  approach,  similar  to  bundled  attributes  of  GKS,  has  proven  to  be 
simple  yet  powerful.  However,  in  the  VGTS  most  values  are  predefined  at  compilc-time;  they  should  be 
dynamically  defined  at  run-time.  For  example,  for  text  fonts  tltc  DefineFont  function  returns  an  attribute  to 
be  used  in  subsequent  Text  items.  Similar  functions  should  be  available  to  define  colors,  fill  patterns,  and 
line  styles. 

In  keeping  with  the  declarative  approach  of  the  VGTS.  each  item  has  its  attributes  explicitly  specified.  For 
example,  if  a  symbol  contains  500  blue  lines,  then  each  line  contains  llic  information  that  its  color  is  blue. 
This  is  in  contrast  to  the  approach  taken  by  traditional  graphics  packages,  which  would  have  a  command  to 
set  the  current  line  color  to  blue  and  then  draw  500  lines.  Although  the  traditional  approach  requires 
additional  state  during  interpretation  of  the  SDF,  it  would  allow  the  inheritance  of  attributes  from  containing 
environments.  An  open  issue  is  die  value  of  diis  inheritance  capability. 


7.6.3  Other  Interfaces 

If  VGTS  allowed  inheritance  of  attributes,  then  it  could  support  an  interface  compatible  with  GKS.  The 
application  could  still  take  advantage  of  the  structuring  capabilities  of  the  VG  I  S  if  the  interface  is  upward- 
compatible  with  GKS,  in  the  manner  of  Steinhart(130].  Such  a  redesign  is  in  progress  at  die  Ume  of  this 
writing. 

Other  virtual  terminal  emulators  could  provide,  for  example.  Nai>ij>s  virtual  terminals  as  another  possible 
interface.  These  interfaces  could  be  implemented  as  an  alternative  library  package,  retaining  the  current 
message  interface.  A  new  message  interface  could  be  designed,  with  the  conversion  to  byte-streams  done  in 
the  'I'lT.NET  programs.  Tlie  reladon  between  the  V-System  concept  of  file  instances  and  VG'l’S  objects  such 
as  SDF,  VGl',  and  VGT  group  could  be  made  cleaner. 


7.6.4  Porting  the  Implementation 

At  the  time  of  this  writing,  although  two  totally  incompatible  frame  buffers  are  supported,  the  VGTS  has 
not  yet  been  fully  ported  to  another  graphics  device  besides  SUN  workstations.  Many  potential  graphics 
devices  were  eidier  too  expensive  or  provide  too  low  a  performance  level  to  adequately  support  an 
implementation  of  the  VG'l'S.  A  port  is  currently  in  progress  to  the  VAXStation,  which  should  prove  diat  the 
implementation  is  independent  of  processor  architecture  as  well  as  graphics  architecture. 


7.6.5  Multiple  View  Surfaces 

Another  aspect  of  the  design  never  fully  exploited  was  die  use  of  multiple  screens  per  workstation.  A 
typical  configuration  might  have  a  color  screen  for  computer  aided  design,  and  a  black  and  white  screen  for 
general  textual  interaction.  Applications  should  nin  with  no  modifications  on  such  a  configuration.  A  natural 
extension  of  the  user  interface  (used  on  other  systems  with  multiple  view  surfaces)  would  have  one  cursor  for 
both  screens.  When  the  cursor  is  moved  past  an  edge  on  one  screen,  it  appears  on  the  edge  of  the  adjacent 
screen. 

Most  of  the  current  VGTS  implementation  could  be  used  with  multiple  view  surfaces.  The  internal  data 
structures  for  views  could  easily  be  augmented  by  a  pointer  to  a  frame  buffer  descriptor  structure,  containing 
pointers  to  die  primitive  functions  to  operate  on  the  particular  frame  buffer.  This  approach  is  similar  to  the 
ptrreef  specification  by  SUN  Microsystems  (123J.  In  fact,  pixrect  would  be  a  good  candidate  for  this  layer, 
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were  it  not  proprietary  to  a  single  manufacturer.  Another  candidate  would  be  one  of  the  Virtual  Device 
Interface  standards,  or  normalized  device  coordinates  at  a  well-specified  internal  interface. 


7.6.6  Extended  Functionality 

Since  the  VGTS  evolved  in  an  environment  rich  in  system  programmers,  there  was  no  shortage  of  suggested 
enhancements,  including  three  dimensional  SDl's,  color,  floating-point,  image  prcKCSsing,  and  general 
coordinate  transfoimations.  Currently  the  few  programs  that  use  floating  point  or  tlircc  dimensions  execute 
on  server  hosts  in  batch  mode,  because  our  workstations  do  not  have  adequate  numeric  performance.  The 
batch  programs  convert  to  two-dimensional  integer  ewtrdinates  tliat  arc  then  displayed  by  the  VG  I  S.  Simple 
animation  is  possible  in  the  current  implementation,  by  defining  successive  sutges  as  symbols  and  then  rapidly 
changing  between  the  symbols.  Future  floating  point  processors  in  workstations  may  make  it  possible  to 
absorb  some  of  tlicse  ftinctions  into  the  workstation’s  viewing  service. 

A  fourth  dimension,  time,  could  also  be  considered  for  actions  like  animation  or  rubber  banding.  One 
approach  would  be  to  add  graphics  primitives  tliat  would  cause  changes  to  the  screen,  but  not  be  stored  in  an 
SDF.  These  would  be  similar  to  temporary  (or  non-retained)  segments  in  the  Core,  but  would  conflict  with 
the  declarative  nature  of  the  current  design.  More  attractive  would  be  to  specify  rubber  banding  or  trajectory 
as  attributes  of  objects. 

7.6.7  View  Adapting  Objects 

One  principle  advantage  of  tlic  up-call  approach  taken  by  most  object-oriented  window  systems  is  the 
ability  for  graphical  objects  to  adapt  to  their  viewing  environment.  For  example,  when  a  view  becomes 
narrower,  document  paragraphs  could  be  reformated  to  break  into  correspondingly  narrower  lines.  Similar 
functionality  could  be  added  to  the  VGTS  in  several  ways.  The  current  VG  TS  includes  a  function  to  return 
die  size  specified  by  die  user  for  a  default  view.  'Iliis  could  be  extended  to  allow  querying  the  view  for  its  size, 
but  requires  some  kind  of  asynchronous  notification  which  would  be  hard  to  cleanly  add  to  the  architecture. 
The  notification  could  be  done  on  the  basis  of  VG  Is  instead  views,  since  VG  Ts  are  already  visible  objects  to 
clients,  and  multiple  views  arc  allowed  per  VG  T.  Flowcver,  in  the  prototype  a  graphics  VG'l'  has  no  size,  and 
a  text  VG  r  is  a  fixed  size  once  created. 

A  more  promising  approach  is  to  specify  the  viewing  constraints  as  additional  attributes  of  the  object.  For 
example,  the  current  prototype  implements  “reference  lines”,  displayed  as  lines  with  text  labels  drawn  near 
the  edge  of  the  views  in  which  they  appear.  'ITius  the  same  object  in  the  same  VG  T  can  appear  differently  in 
different  sized  views.  Ihc  key  problem  is  to  design  a  mctliod  of  specifying  tlicse  viewing  constraints  with 
more  generality  but  retaining  adequate  performance  at  viewing  time. 


7.6.8  ViewManagerSeparation 

One  of  the  most  requested  areas  of  cuslomi/alion  was  tlic  view  manager.  The  VG  I  S  architectural 
distinction  between  the  application  program’s  interface  and  the  user's  inlcifacc  means  Uiat  users  should  be 
able  to  experiment  with  alternate  or  parameterized  view  managers  without  affecting  any  application 
programs.  For  example,  tiled  and  overlapped  viewports  should  both  be  provided.  In  addition,  work  needs  to 
be  done  to  develop  more  advanced  command  interfaces  on  top  of  the  VGTS. 
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7.7  Final  Evaluation 

Even  with  tlic  deficiencies  noted  in  Section  7.5,  few  other  systems  provide  as  powerful  a  set  of  features  on 
equivalent  workstations.  The  VC  TS  approach  is  well-suited  to  environments  under  the  following  conditions: 

1.  Workstations  can  provide  adequate  user  response  without  requiring  performance  extremely  close 
to  hardware  speeds. 

2.  Computing  resources  much  more  powerful  than  workstations  are  available  across  some  kind  of 
network. 

3.  Portability  and  device  independence  is  important  due  to  a  heterogeneous  or  rapidly  changing 
hardware  base. 

4.  Productivity  of  potential  users  could  be  increased  by  providing  multiple  simultaneous  contexts. 

5.  Application  programs  deal  primarily  with  incremental  changes  or  structured  pictures  instead  of 
producir  g  images  to  be  only  viewed  once. 

As  a  result,  the  VG  I  S  is  in  daily  use  at  Stanford  and  several  other  sites.  Moreover,  it  has  been  valuable  for 
the  performance  measurements  and  design  studies  described  here. 
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—  Appendix  A  — 
Glossary 

This  work  encompasses  three  different  suhficlds  of  computer  science:  Operating  Systems,  Networks,  and 

Computer  Graphics.  Unfortunately  some  terms  have  different  meanings  in  more  than  one  of  these  fields. 

This  glossary  should  help  to  provide  one  set  of  consistent  definitions.  Many  of  these  definitions  arc  adapted 

from  the  literature  1 161, 64],  while  others  arc  particular  to  this  work,  l-'or  more  details,  refer  to  tlic  references 

provided  in  the  bibliography  or  tlic  text  section  as  indicated. 

AiaiS  A  system  developed  by  Robert  Sproull  at  Xerox  Palo  Alto  Research  Center  [127]  to  allow  an 

Interl.isp  program  running  on  a  tiincshared  computer  to  perform  raster  graphics  operations 
on  a  workstation. 

Ansi  American  National  Standards  Institute.  In  tlic  United  States  such  standards  arc  voluntary 

only.  Computer  related  spindards  can  be  obtained  from  the  X3  Secretariat  at  tlic  Computer 
and  Business  Hquipment  Manufacturers  Association  in  Washington  D.  C. 

Arpa  Advanced  Research  Project  Agency  of  the  United  States  Department  of  Defense.  An  agency 

that  funds  major  computer  science  research  projects,  including  the  Arpanli,  a  nation-wide 
computer  network  [106]. 

APA  All  Points  Addressable.  IBM  terminology  for  a  bitmap  raster  graphics  device. 

Backend  The  part  of  a  computer  system  (hardware  or  software)  that  docs  not  interact  with  a  user.  It  is 

separated  from  interaction  with  the  user  by  tlic  front  end.  For  hardware,  backends  can  be 
optimized  for  batch  operation,  favoring  throughput  over  response  time.  For  software, 
requests  are  made  from  other  programs  or  software  modules  instead  of  directly  by  the  user. 

BcPL  Basic  Cambridge  Programming  l  anguage.  A  very  simple  language  with  control  structures 

but  no  data  structuring  facilities. 

BitBlt  Bit-boundary  Bl.ock  Transfer.  'ITic  operation  of  moving  blocks  of  bits  from  and  to  arbitrary 

IcKations  within  computer  words. 

Bitgraph  A  terminal  built  and  marketed  by  Bolt  Bcranck  and  Newman  of  Cambridge,  Massachusetts, 
based  on  an  MC68000  processor  and  a  bitmap  display. 

Bitmap  A  digital  image  memory  containing  a  description  of  each  of  the  addressable  pixels  in  a  raster 

display.  The  cohir  or  intensity  level  of  each  pixel  is  directly  detennined  by  tlic  value  of  a  set 
of  bits  in  the  bitmap. 

Blit  A  terminal  built  at  Bell  Laboratories  based  on  an  MC68000  pnrccssor  and  a  bitmap 

display  [72].  A  reengineered  vci-sion  is  being  marketed  under  the  name  Teletype  5620.  Ilic 
screen  management  software  supplied  for  the  Blit  is  called  I  .ayers  [105]. 

BSP  Byte  Stream  Protocol.  A  transport  protocol  in  the  PUP  Internetwork  Architecture  [19].  BSP 

implements  a  reliable  virtual  circuit  on  top  of  the  internet  datagrams  of  the  network  layer. 

C  A  programming  language  designed  at  Bell  Laboratories  for  the  Unix  operating  system  [71]. 

The  language  is  above  die  level  of  assembler,  but  allows  machine-dependent  constructions 
for  low-level  systems  programs  such  as  device  drivers. 


CAD 


Computer  Aided  Design.  'The  application  of  computers  to  the  design  process. 
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Cages 

Calcomp 

Cedar 

Clipping 

Core 

CPU 

Cursor 

Datagram 

DFS 

Display  File 
DISD» 

Dragging 

f>)rado 

Dynab(X)k 

Hmacs 

Escape 

Ethernet 


Configurable  Applications  for  Graphics  Employing  Satellites,  A  system  developed  at  the 
University  of  North  Carolina  that  allowed  a  programmer  to  assign  modules  in  interactive 
graphics  programs  to  one  of  two  processors  at  load  time  [62],  The  implementation  used  an 
IBM  360/75  connected  to  a  DEC  PDP-11/45  with  88K  bytes  of  memory.  Programs  were 
written  in  a  subset  of  PL/1. 

California  Computer  Corporation.  An  early  manufacturer  of  computer  graphics  output  (pen 
plotting)  devices. 

An  experimental  computing  environment  developed  at  Xerox  Palo  Alto  Research 
Center  [46],  using  the  language  Mesa  [99]  with  extensions  taken  from  IntcrI.isp  [138]. 

A  process  to  insure  that  an  image  lies  within  a  certain  (usually  rectangular)  boundary  of 
visible  space. 

A  graphics  subroutine  package  specification  developed  in  1979  by  the  ACM  Siggrapii 
Graphics  System  Planning  Committee  [147]. 

Central  Processing  Unit,  '["he  part  of  a  computer  system  that  fetches  and  executes 
instructions. 

A  special  symbol  used  to  specify  a  particular  position  on  a  screen. 

A  network  protocol  in  which  every  packet  includes  a  full  address  and  is  routed  separately 
from  all  other  packets.  'Phis  is  in  contrast  to  virtual  circuit  networks  in  which  addressing  and 
routing  arc  performed  on  a  connection  basis. 

Distributed  File  System.  .A  general  concept  (providing  network  transparent  file  access),  and 
in  particular  a  project  at  the  Xerox  Palo  Alto  Research  Center  to  develop  a  distributed  file 
system  [134], 

A  data  structure  used  to  generate  an  image.  Foley  and  van  Dam  discuss  the  many  possible 
uses  for  display  files  [56].  Alternately  called  display  lists  or  display  buffers. 

Device  Independent  Structure  DataBase.  A  concept  in  the  I^iwrcncc  Berkeley  Ixaboratorics 
Network  Graphics  System  [24],  similar  to  tlic  Wiss  of  GKS.  Application  programs  use  the 
workstation-independent  layer  to  create,  modify,  and  delete  information  in  the  dabibase, 
while  the  workstation-dependent  layers  read  the  structure  information  to  update  tlic  displays. 

'ITic  translation  of  a  selected  displayed  object  along  a  path  .specified  by  a  graphic  input  device. 
'Ihis  is  a  form  of  image  transfomiation. 

A  high-performance  personal  scientific  computer  built  at  Xerox  PARC  [75J. 

A  concept  of  a  powerful  portable  personal  computer  system  that  could  be  used  in  education 
much  like  a  notebook  iscurrciUly  licing  used  [90]. 

A  screen  display  editor  that  is  extensible  by  using  an  interpreter  for  a  powerful 
language  [129],  Ihc  original  version  was  implemented  in  1974  for  tlvc  Dl-fSystcm-lO  and 
Dl-cSystcm-20  line  of  computers.  'ITicrc  arc  now  many  versions  for  a  variety  of  machines 
and  operating  systems. 

A  facility  to  access  functions  tliat  arc  normally  not  part  of  the  interface  specification. 

A  patticular  kind  of  local  area  network  that  uses  carrier  sense  multiple  access  with  collision 
detection.  'Ihc  official  spa'ification  for  tlic  daui  link  and  physical  layers  was  developed 
jointly  by  Xerox,  Digital  Fx^uipment,  and  Intel  Corporations  [44], 
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Extent 

Frame  Buffer 
Frontend 

GKS 

Hit  Detection 

ICOl»S 

IKP 

Inquire 

InterLisp 

IP 

Iptn 

Iris 

ISO 

Keystroke 

layers 

IRC 

Mainframe 

Mbyte 

MCbsono 


Also  called  the  bounding  box.  The  smallest  orthogonal  rectangle  containing  the  object  in 
question.  This  is  obtained  by  calculating  tlie  maximum  and  minimum  coordinates  of  the 
objects  along  each  axis. 

'fhe  digital  memory  used  to  store  the  bitmap  in  a  raster  display. 

Tlic  part  of  a  computer  system  that  deals  with  tlic  user.  The  frontend  should  be  optimized 
for  fast  response  time,  with  longer  operations  made  part  of  the  backend. 

Graphical  Kernel  System.  A  sLmdard  graphics  package  definition  adopted  by  the 
International  SUindards  Organi/iition  [64]  and  the  American  National  Standards  Institute. 

'Hie  operation  of  associating  an  event  on  a  graphics  input  device  with  an  item  in  tlie  display 
list  1’his  is  the  function  of  a  Pick  device. 

Interconnected  Processor  System.  A  graphics  system  developed  at  Brown  University  to 
dynamically  distribute  parts  of  an  application  program  between  two  processors  [97, 146, 128], 
an  IBM  360/67  and  a  Meta  4  with  64K  bytes  of  memory  and  a  50K  bits  per  second  serial 
connection.  A  single  application  program  written  in  the  Algol-W  language  was  used  for 
performance  measurements. 

Inter-Kernel  ProhKol.  The  protocol  used  in  the  V-System  between  kernels  to  provide  the 
transparency  of  message  passing. 

Operations  that  return  information  from  the  graphics  system. 

An  experimental  computing  environment  developed  at  Xerox  Palo  Alto  Research  Center, 
based  on  a  form  of  the  Lisp  language  [138].  The  InterLisp  system  has  been  ported  to  several 
different  computing  environments,  from  personal  computers  to  timesharing  systems. 

Internet  Protocol  [106].  A  network-level  protocol  used  in  the  ARPANET, 

Internet  Protocol  TclNct  The  V-System  program  that  allows  a  user  to  have  a  terminal 
session  on  a  remote  server  host 

Integrated  Raster  Imaging  System.  A  high-performance  color  graphics  workstation 
developed  at  Suinford  Univereily  [39],  and  now  marketed  by  Silicon  Graphics,  Inc.  of 
Mountain  View  California. 

International  Standards  Organization. 

One  user  action,  such  as  pressing  a  key  on  a  keyboard.  Used  to  model  the  psychology  of 
human-computer  interaction  [26]. 

A  software  system  developed  for  the  Blit  tenninal  developed  by  Bell  l.aboratories  [105], 

I. caring  Research  Group.  Tlic  group  that  developed  tlic  SmallUilk  language;  called  tlic 
Software  Concepts  Group  since  1981. 

A  very  large  and  expensive  computer,  typically  purchased  by  a  group  and  maintained  in  a 
computer  room. 

Megabyte.  The  twentieth  power  of  two,  number  of  bytes,  usually  referring  to  computer 
memory.  Actual  number  is  1048576,  significantly  larger  tlian  one  Million. 

A  currently  popular  microprocessor  produced  by  Motorola  Conioration  [100].  It  is  a  32  bit 
architecture  (69).  with  several  dilTcrent  implementations.  Unfortunately  tliis  name  was  used 
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Mesa 

Mh/ 

Mips 

Mouse 

Mux 

Nabts 

Naplps 

nix: 

NGP 

NGS 

NLS 

Nmos 

NVT 

Parc 

Pel 

Perq 

PlllGS 

Pick 

Pilot 


for  both  the  architecture  and  the  first  bn  piemen  tation  (a  16  bit  implementation  with  23 
address  bits). 

A  language  developed  at  Xerox  PARC  for  writing  systems  programs.  Mesa  supports  systems 
of  separate  modules  with  controlled  sharing  of  information,  'flic  basic  Mesa  language  has 
been  extended  in  the  Cedar  experimental  programming  environment  [46]. 

McgaHcrtZ.  One  million  cycles  per  second.  One  parameter  of  microcomputer  performance 
is  the  clock  speed. 

Million  Instructions  Per  Second.  A  common  (but  inaccurate)  measure  of  computer  system 
performance. 

A  graphics  input  device  that  operates  by  sensing  relative  position  changes  when  traveling 
over  a  flat  surface  [SO]. 

Multiplexor.  A  device  which  mediates  between  several  entities  all  wishing  to  use  a  common 
resource. 

North  American  Broadcast  'I'cletext  Specification  [11]. 

North  American  Presentation  Ixvel  Protocol  Syntax  [6]. 

Normalized  Device  Coordinates.  A  very  low-level  but  resolution  independent  coordinate 
system.  For  example,  the  coordinates  of  the  view  surface  as  floating  point  numbers  ranging 
from  zero  to  one  with  (0,0)  the  lower  left  corner  and  (1,1)  the  upper  righL 

Network  Graphics  Protocol.  The  transport  layer  protocol  used  to  communicate  between  a 
workstation  and  the  system  running  a  remote  graphics  application. 

Network  Graphics  System.  Designed  at  the  Ixwrence  Berkeley  Laboratory  [25],  and  partially 
implemented  [24]. 

oN-Linc  System.  A  software  system  developed  at  SRI  [49]  that  used  computers  with  graphics 
workstation  to  augment  tlie  abilities  of  knowledge  workers.  It  iS  now  marketed  by  'lymesharc 
Corporation. 

N-channcl  Metal  Oxide  Silicon.  A  prwess  for  making  very  large  scale  integrated  circuits  [93]. 

Network  Virtual  Terminal.  A  concept  originally  developed  for  long-haul  networks  [162],  to 
ease  the  connection  of  a  variety  of  real  terminals  to  a  variety  of  computer  systems  without 
having  to  support  all  possible  combinations. 

ITie  Xerox  Palo  Alto  Research  Center. 

IBM  terminology  for  Pixel. 

A  workstiition  built  by  'Mircc  Rivers  Corporation  [144]. 

Programmer’s  Hierarchical  Intcrfiicc  to  the  Graphics  System.  A  draft  standard  for  a  graphics 
package  with  hierarchical  segment  structure  [4]. 

A  graphical  input  event  which  returns  the  identification  of  an  item  within  a  display  file. 

An  operating  system  for  workstations  developed  at  Xerox  Parc,  written  in  tlie  Mesa 
language  and  used  as  tlic  basis  for  the  Xerox  Development  Imvironmcnt  [160]. 
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Pixel  Picture  ElcmcnL  The  smallest  display  area  on  a  raster  display  surface  whose  characteristics 

can  be  controlled  independently  of  its  neighbors. 

Pixrect  A  layer  in  the  graphics  architecture  of  SUN  Microsystems  Inc.  (123). 

Pop-up  A  type  of  menu  that  only  appears  when  a  choice  must  be  made. 

Pty  Pseudo-terminal.  An  operating  system  object  tliat  behaves  as  a  terminal  on  one  side,  but 

communicates  to  a  program  (typically  a  server  'I'lXNiri  )  on  the  other  side. 

Raster  A  rectangular  array  of  pixels.  A  raster  display  is  one  that  use  an  array  of  pixels  to  produce  the 

image,  in  contrast  to  a  scries  of  lines,  for  example. 

RastcrOp  A  Raster  Operation.  One  of  tlic  many  bit-oriented  operations  between  one  two  bit-arrays 
producing  another  bit-array  [103). 

RPC  Remote  PrcKcdurc  Call.  An  attempt  to  preserve  tlic  semantics  of  local  procedure  calls  across 

a  network,  usually  done  as  an  extension  to  a  compiler  [102).‘ 

RS-232  A  Recommended  Standard  232  of  the  Electronics  Industries  Association.  Used  to  connect 

most  low  to  medium  speed  terminals  to  computers,  fhe  communication  is  full-duplex  using 
twisted  pairs  between  two  points,  over  short  distances.  A  functionally  similar  interface  used 
outside  the  United  States  is  ccriT  specification  V24. 

RTP  Rendez-vous  and  'fermination  Protocol.  Part  of  the  PUP  Internetwork  Architecture  [19), 

used  to  set  up  and  terminate  byte  stream  protocol  connections. 

Rubber  Banding 

An  interactive  technique  that  moves  the  common  vertex  of  one  or  more  objects  such  as  lines 
while  tlic  other  end  points  remain  fixed. 

Scan  Conversion 

'llic  process  of  converting  an  image  defined  in  terms  of  graphical  objects  into  a  raster  (array 
of  pixels). 

Screen  CiMirdinates 

Device  dependent  coordinates,  usually  integer  raster  units.  Only  the  lowest-level  device 
driver  uses  Uiis  coordinate  system. 

Scrolling  Continuous  vertical  (or  horizontal)  movement  of  display  elements  within  a  viewport  As  new 
objects  appear  at  one  edge  (such  as  lines  of  text  along  the  bottom),  old  objects  disappear  at 
tlic  opposite  edge. 

SDE  Structured  Display  Eilc.  A  directed,  acyclic  graph  of  items,  each  of  which  is  cither  a  primitive 

item  or  a  symbol,  which  is  a  list  of  other  items.  SDEs  are  manipulated  via  the  VG  TP,  which 
is  described  in  Section  3.4. 

Segment  An  ordered  collection  of  output  primitives  defining  an  image. 

SIGGRAPII  Association  for  Computing  Machinery  Special  Interest  Group  on  computer  Graphics. 

Smalltalk  A  language  and  system  developed  at  the  Xerox  Learning  Research  Group,  now  known  as  the 
Software  Concepts  Group  [58). 

SUN  Sumford  University  Network.  Also  applies  to  a  particular  workstation,  a  trademark  of  SUN 

Microsystems  Incorporated. 
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Symbol  A  list  of  graphical  items  grouped  together  and  given  a  name.  'Phis  name  can  be  used  to  add 

instances  of  the  symbol  to  other  symbols,  producing  levels  of  structure  in  an  SDF. 

TCP  Transmission  Control  Protocol.  A  transport  protocol  in  the  Arpa  protocol  architecture  (106). 

Telnet  A  protocol  to  allow  remote  logins  [I07J. 

TOI*S-20  A  timesharing  system  from  Digital  Equipment  Corporation  for  the  DECSystcm-20  line  of 
computers. 

Unix  A  portable  timesharing  system  developed  by  AT&T  Bell  I  .aboratories  in  the  early  1970s  (1 1 IJ. 

User  The  human  end-user  of  a  computer  system  or  set  of  software.  Thus  the  user  interface  deals 

with  the  person  trying  to  use  the  system  to  get  work  done,  in  contrast  to  the  programmer 
interface  which  is  used  by  the  developer. 

VAX  Virtual  Address  extension.  A  line  of  computers  built  by  Digital  Equipment  Corporation 

with  a  32  bit  architecture  (451. 

VDl  Virtual  Device  Interface.  A  proposed  standard  interface  between  a  graphics  package  and  a 

device  driver,  as  shown  in  Figurc.2-2. 

VDM  Virtual  Device  Metafile.  A  method  for  storing  graphics  information  on  a  file.  Figure  2-2 

illustrates  how  VDM  fits  into  the  architecture  of  standard  graphics  packages. 

VGT  Virtual  Graphics  Terminal.  A  concept  of  the  VG'I'S  which  combines  advantages  of 

traditional  graphics  packages  and  window  systems  within  the  framework  of  a  virtual  terminal 
management  system.  Section  3.4.2  defines  the  semantics  of  a  VGT.  which  is  associated  with 
one  item  in  an  SDF  (usually  a  symbol). 

VGIP  Virtual  Graphics  Terminal  Protocol.  The  protocol  used  between  the  VG’I'S  and  a  client 

Described  in  Section  3.4. 

View  A  mapping  of  a  virtual  terminal  onto  a  physical  output  device.  Default  views  are  provided  by 

the  application  programmer,  while  the  user  creates  and  manipulates  views  with  the  View 
Manager,  as  described  in  Section  4.4. 

Viewport  A  rectangular  area  of  a  physical  output  device  which  presents  the  contents  of  a  window.  'I’he 
VG  TS  prototype  implementation  supports  potentially  overlapping  viewpoHs,  so  the  actual 
areas  of  the  screen  that  are  visible  for  each  viewport  arc  called  subviewports.  Section  4.2.1 
describes  tliis  procc.ss  in  more  detail. 

V-Kerncl  A  small  real-time  portable  operating  system  kernel  [31],  descended  from  'nu)th{29]  and 
Verex  (30). 

VLSI  Very  Dirge  Scale  Integration  193).  VLSI  is  both  tlic  reason  why  graphics  workstations  arc 

becoming  economical,  and  one  ofllic  major  users  of  Utosc  workstations. 

VMS  Virtual  Memory  System.  '1110  operating  system  supplied  by  Digital  Equipment  Corporation 

for  the  VAX  computer  [45]. 

V-Server  A  program  running  within  some  predefined  operating  system  that  provides  services  such  as 
file  access  and  remote  execution  to  clients  in  a  V-System  (31]. 

V-System  A  system  of  distributed  servers  and  a  synchronous  mcs.sagc-bascd  kernel  developed  by  the 
Distributed  Systems  Group  of  Stanford  University  (17). 
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VT 

Vtms 

Wdss 

WlSS 

Window 

Woodstock 


Virtual  Terminal.  A  concept  originally  developed  for  long-haul  networks  [162],  to  ease  the 
connection  of  a  variety  of  real  terminals  to  a  variety  of  computer  systems  without  having  to 
support  all  possible  combinations. 

VirtualTerminal  Management  System.  An  agent  in  the  Rochester  Intelligent  Gateway  which 
managed  terminal  interaction  [77]. 

Workstation  13cpcndcnt  Segment  Storage.  A  concept  used  in  GKS  [64]. 

Workstation  Independent  Segment  Storage.  A  concept  used  in  GKS  [64]. 

I1iat  part  of  the  virtual  (or  world)  coordinate  space  that  is  being  displayed  in  a  particular 
view.  This  is  the  stmdard  graphics  package  tcnninology  [147],  in  contrast  to  the  “window 
system”  terminology  (see  Chapter  2)  which  uses  the  tcim  to  refer  to  the  view  itself. 

A  stateless  file  server  project  at  Xerox  PARC  [137].  One  of  the  first  experiments  at 
partitioning  between  an  application  program  and  its  disk. 
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World  Coordinates 

llie  coordinate  system  of  the  application  program’s  model  of  an  object.  The  input  to  the 
viewing  pipeline  in  most  graphics  systems  [147]. 


Workstation 


A  computing  resource  dedicated  to  a  user.  This  may  range  from  a  small,  fixed- function 
terminal  to  a  large  self-contained  personal  computer. 


Zoom 


Changing  the  scaling  factor  mapping  from  virtual  coordinates  to  physical  coordinates  to  give 
the  appearance  of  having  moved  towards  or  away  from  the  object  of  interest. 
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—  Appendix  B  — 
A  Short  VGTS  Sample  Program 

The  following  program  has  actually  been  run  both  under  Unix  and  under  the  V  system  executive.  The 
#i  f  def  Vsystem  directives  allow  die  programmer  to  conditionally  compile  code  for  one  environment  or 
the  other.  It  also  must  be  compiled  with  the  appropriate  compiler  and  linked  with  the  correct  library.  It  first 
creates  an  SDK  and  VGT,  then  displays  100  random  objects  of  various  kinds. 


•  test.c  -  a  test  of  the  remote  VGTS  implementation 

*  Bill  Nowicki  September  1982 

•/ 

#  include  <Vgts.h> 

#  include  <Vio.h> 


#  define  Objects  100  /•  number  of  objects  •/ 

short  sdf,  vgt; 

Quit( ) 

{ 

DeleteVGT(vgt,l); 

DeleteSDF(sdf); 

ResetTTY(); 
exit( ) ; 

} 

main( ) 

{ 

int  i : 
short  item; 
long  start,  end; 

#  ifndef  Vsystem 

printf ( "Remote  VGTS  test  programXn"); 

#  else  Vsystem 

printf ("VGTS  test  programXn"); 

K  endif  Vsystem 

ff lush(stdout) ; 

GetTTY( ): 

sdf  =  CreateSDFO: 

Def ineSymbol (  sdf,  1,  "test"  ); 

Addltem(  sdf,  2,  4,  40,  4,  60,  NM,  SDF_FILLED_RECTANGLE ,  NULL  ); 
EndSymbol(  sdf,  1,  0  ); 

vgt  =  CreateVGT(sdf ,  GRAPHICS+ZOOMABLE ,  1,  "random  objects"  ); 
DefaultView(vgt,  500,  320,  0,  0,  0,  0,  0,  0); 
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t1me(&start) : 

for  (1=12;  i<0bjects;  1++  ) 

{ 

short  X  =  Random(  -2,  155); 
short  y  =  Random(  -10.  169); 
short  top  =  y  +  Random(  6.  100  ); 
short  right  =  x  +  Randoin(  4,  120  ); 
short  layer  =  Random(  NM,  NG  ); 

EditSymbo1(sdf ,  1); 

Deleteltein(  sdf,  1-10); 
switch  (Randoni(l,  6)  ) 

{ 

case  1: 

Addltem(  sdf.  1.  x.  right,  y.  top.  layer. 
SDF_FILLEO_RECTANGLE.  NULL  ); 

break; 
case  2: 

Addltem(  sdf.  1.  x.  x+1000.  y.  y+16.  0.  SDF_SIMPLE_TEXT. 

"Here  Is  some  simple  text”  ); 
break; 

case  3: 

Addltem(  sdf.  1,  x.  right,  y.  y+1.  0, 
S0F_H0RIZ0NTAL_LINE.  NULL  ); 

break; 


case  4: 

Addltem(  sdf,  1,  x,  x+1.  y,  top,  0, 
SOF_VERTICAL_LINE.  NULL  ); 

break; 


case  5: 

Addltem(  sdf,  1.  x,  right,  y,  top,  0, 
SDF_GENERAL_LINE,  NULL  ); 

break; 
case  6: 

Addltem(  sdf,  1,  x,  right,  top.  y,  0, 
SDF_GENERAL_LINE.  NULL  ); 

break; 

} 

EndSymbo1(  sdf,  1.  vgt  ); 

} 

t1me(&end) ; 

If  (end==start)  end  =  start+1; 

pr1ntf("%d  objects  In  %d  seconds,  or  %d  objects/second\r\n" , 
Objects,  end-start,  Objects/(end-start)); 
pr Intf ( "Done  I \r\n" ) ; 

Quito; 


A  SHORT  vors  SAMPLIi  PROGRAM 


Random(  first,  last  ) 

{ 

/• 

*  generates  a  random  number 

•  between  "first"  and  "last"  inclusive. 

•/ 

int  value  =  rand()/2: 
value  %=  (last  -  first  +  1); 
value  +=  first; 
return( value) ; 

} 


HISTORY  OFniE  IMPLEMENTATION 
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—  Appendix  C  — 
History  of  the  Implementation 


The  S13F  manager  was  originally  written  by  Charles  “Rocky”  Rhodes,  incorporated  into  the  Yale  VLSI 
layout  program  by  Tom  Davis  [42],  and  converted  to  use  tlic  V  kernel  by  Marvin  Theimer  during  the  summer 
of  1982.  Most  of  the  conversion  into  the  VGTS  by  die  author  was  done  in  late  summer  and  fall  of  1982,  with 
significant  events  as  follows: 

July.  1982 

The  Yale  program  was  converted  to  run  under  the  V  kernel. 

August  27, 1982 

The  SDF  manager  operations  could  be  called  via  C  function  calls  from  the  Yale 
program,  but  was  a  separate  module.  T  he  window  manager  and  related  drawing 
routines  could  be  linked  together  with  any  client  wanting  to  use  them. 

September  1, 1982 

A  terminal  program  was  written  to  combine  standard  terminal  emulation  functions,  a 
PUP  User  TEI NIH'  implementation,  and  the  SDF  manager  functions  in  one  program. 
This  was  based  on  an  earlier  implementation  of  PUP  User  titnee  by  the  author. 

September  18, 1982 

'Fhe  terminal  program  was  augmented  to  decode  the  escape  sequences,  so  that  a 
program  running  on  a  remote  host  could  manipulate  an  SDF.  A  set  of  “stub”  functions 
was  written  that  allowed  programs  to  run  either  on  the  SUN  dircedy  or  on  any  host 
reachable  through  a  telnet  connection. 

October  2,  1982 

Yale  was  ported  to  die  vax.  using  the  stub  routines  to  simulate  die  local  VGTS 
environment.  A  few  remote  test  programs  were  written  at  this  dme,  including  the 
program  in  Appendix  B. 

November  1, 1982 

Overlapping  viewports  added.  Arbitrary  lines  were  also  added  and  debugged.  Another 
test  program  to  display  wire-frame  drawings  projected  from  three  dimensions  was 
written. 

January  1983 

A  simple  illustration  editor  was  written  by  die  author  to  edit  diagrams  for  papers  on  the 
VGT’S.  All  of  the  diagrams  in  this  thesis  arc  produced  with  this  program. 

February  17,  1983 

The  text  editor  Ved  operated  under  the  VGT’S  along  with  other  executives. 

March  5, 1983 

Graphics  applications,  including  previously  mentioned  test  programs,  and  both  the 
distributed  and  ItKal  versions  of  the  Yale  program  were  operated  under  the  VGT’S 
and  coexisted  with  each  other.  The  VGT’S/Hxccutivc  combination  was  installed  for 
production  use  by  other  members  of  the  Distributed  Systems  Group. 

March.  1983 

The  abil""  to  display  text  in  arbitrary  fonts  was  added,  in  addition  to  the  special 
fixcd-wioth  font. 

April  5,  1983 

Continuous  mouse  monitoring  added,  so  real-time  feedback  was  possible.  With  these 
new  additions  to  tlic  illustrator  program,  and  the  Ved  editor,  usability  was  greatly 
increased.  The  view  manager  also  provided  feedback  when  positioning  viewports. 

April  20. 1983 

Raster  objects  were  added,  and  a  test  program  which  displays  half-tone  photographic 
images  was  written.  Another  test  program  successfully  displayed  a  database  containing 
a  map  of  the  world. 

May.  1983 

Filled  polygons  and  splines  were  added,  and  a  drawing  editor  program  was  developed 
to  test  them. 

•  -  »  •  Jl  '  k  “Jk  ■ 

no 


PARTITIONING  OF  FUNCT  ION  IN  A  DISTRIBUTED  GRAPHICS  SYSTEM 


July,  1983  Banners  added  and  integrated  into  the  executive.  Screen  saver  added  to  turn  off  SUN 

video  if  nothing  has  happened  in  the  last  ten  minutes.  View  manager  menus  were 
reorganized. 

September,  1983  Added  line  editor  and  integrated  into  the  executive.  Removed  line  editors  from  most 
application  programs.  Added  directory  prot(x:ol  support. 

November,  1983  Split  off  exec  server  instead  of  linking  directly  to  executives. 

July,  1984  Initial  port  to  the  SUN-2  frame  buffer.  Only  simple  text  and  rectangle  objects  worked 

at  this  point.  View  manager  shortcuts  installed. 

Other  people  who  have  contributed  to  the  VG'I’S  implementation  were  as  follows: 

P.  M.  Bothner  Primitives  for  display  of  rasters  and  arbitrary  fonts,  on  both  SUN-1  and  SUN-2  frame 
buffers. 

K.  P.  Brooks  Continuous  mouse  monitoring,  arc  and  fast  filled  polygons,  design  of  GKS  compatibility 

package. 

D.  R.  Chcriton  13csign  of  I/O  protocol,  and  the  V  kernel;  Co-principal  investigator  for  the  Distributed 
Systems  Group. 

T.  R.  Davis  Original  application,  which  was  integrated  with  SDF  management  and  display  routines,  as 
well  as  original  view  manager  in  the  Yai,e  program. 

J.  C.  Dunwoexly  Automatic  pagination  of  pad  output,  simple  terminal  server,  mouse  text  selection  for  line 

editor. 

R.  S.  Finlayson  Port  to  the  SUN-2  frame  buffer,  including  most  of  the  graphics  primitives  for  the  SUN-2. 

L.  Gass  Hit  detection  functions  (FindSelectedObJeci). 

D.  R.  Kacibling  Filled  splines  and  polygons,  and  an  application  program  that  uses  them  (Draw). 

K.  A.  Lantz  Virtual  Terminal  concept,  overall  architecture  of  user  interface;  research  supervisor,  and 

Co-principal  investigator  for  the  Distributed  Systems  Group. 

T.  P.  Mann  V-Kcrncl  support  for  frame  buffer  access,  many  minor  bug  fixes  in  related  software. 

J.  I.  Pallas  Improved  cursor  visibility,  some  minor  bug  fixes,  and  short  cuts  to  get  to  view 

management  functions. 

V.  R.  Pratt  Fast  vector  drawing  flinction  implementation. 

C.  C.  Rhodes  Initial  SDI’  management  functions,  partial  port  to  the  Iris, 

M.  M.  'Ihcimcr  Conversion  of  Yai.f;  to  die  V-System,  and  the  internet  server. 

Undoubtedly  ilicrc  arc  others  who  have  helped  in  one  way  or  another,  but  these  arc  the  major  contributors. 
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—  Appendix  D  — 
Detailed  Experimental  Results 

ITiis  appendix  contains  the  specific  results  from  benchmarks  and  instrumentation  discussed  in  Chapter  6. 
There  arc  three  kinds  of  synthetic  bcnclimarks:  text,  graphics,  and  structure.  Measurements  were  also  taken 
from  the  illustration  editor,  using  the  illusuations  in  this  diesis  as  data.  Within  each  kind  of  benchmark  the 
results  arc  grouped  first  by  workstation  type,  which  appears  in  the  first  column.  The  following  workstations 
were  used  for  the  tests: 

Sun-1  This  was  the  first  model  of  workstation  marketed  as  model  100  by  Sun  Microsystems,  Inc.  of 
Mountain  View,  California.  It  is  connected  to  experimental  (3  Mbit/sccond)  l-'thcrnct  with  a 
controller  built  by  Sun  Microsystems.  It  contains  a  lOMhz  MC68000  processor,  with  IMbytc 
of  memory  accessed  with  no  wait  slates.  Keyboard  and  optical  mouse  arc  polled  by  software. 

Sun-1.5  This  was  the  first  upgrade  to  the  Sun-1  by  Sun  Microsystems,  called  model  lOOU.  It  is 
connected  to  standard  10  Mbit/sccond  Hdicrnct  with  a  controller  made  by  3Com 
Corporation,  also  of  Mountain  View,  California.  It  contains  a  lOMhz  MC68010  processor, 
with  2Mbytc  of  memory  accessed  with  wait  states,  with  a  resulting  effective  speed  of  about 
8Mhz.  Keyboard  and  optical  mouse  arc  polled  by  software. 

Sun-2upg  This  was  another  upgrade  to  the  same  physical  workstation  made  by  Sun  Microsystems,  also 
called  model  2/100.  It  contains  a  lOMhz  MC68010  processor,  with  2Mbytc  of  memory 
accessed  with  no  wait  states.  It  is  connected  to  standard  10  Mbit/sccond  Htlicrnct  with  a 
controller  made  by  3Com  Corporation.  Keyboard  and  optical  mouse  arc  polled  by  software. 
It  is  actually  slightly  slower  on  graphics  tlian  the  Sun-1,  probably  due  to  a  different  bus 
arbitration  circuit. 

Sun-2  This  was  the  second  workstation  product  made  by  Sun  Microsystems,  called  model  2/120.  It 
contains  a  lOMhz  MC68010  processor,  with  2Mbytc  of  memory  accessed  with  no  wait  states, 
tlic  same  prcKCssor  as  tlic  Sun-2upg.  but  a  different  graphics  architecture.  The  screen  bitmap 
is  larger  than  the  previous  Suns,  but  is  addressed  as  linear  memory  instead  of  the  clever 
scheme  of  die  Sun-1.  This  makes  smaller  operations  much  slower,  while  large  operations 
Like  about  the  s;imc  time.  It  is  connected  to  suindard  10  Mbit/sccond  lithcrnct  with  a 
controller  made  by  3Com  Corporation.  Keyboard  and  optical  mouse  arc  connected  by 
RS232  serial  lines. 

Cadlinc  An  older  but  similar  workstation  design,  with  an  8Mh/.  MC68000  prcxrcssor.  Only  512K 
bytes  of  memory  arc  accessed  with  no  wait  states,  and  anotlicr  512K  bytes  arc  available  on  the 
Multibus.  Keyboard  and  mechanical  mouse  arc  controlled  by  a  dedicated  microprocessor, 
connected  to  tlic  MC68000  through  an  RS232  serial  connection. 


The  following  server  hosts  were  used  in  the  experiments: 

Diablo  A  Vax-11/780  running  4.1  Unix  during  experiments,  with  4  Mbyte  memory,  connected  to 
3Mbit/sccond  Fxperimental  Ethernet.  Operated  by  the  SuMEX  project  in  the  Stanford 
University  Medical  Center. 

Navajo  A  Vax-1  1/780  mnning  4.1  Unix  during  experiments,  with  4  Mbyte  memory,  connected  to 
3Mbit/sccond  l'.xpcrimcntal  Ethernet.  Owned  by  the  Stanford  Numerical  Analysis  group 
of  the  Computer  Science  l3epartmenL 

Whitney  A  Vax-11/780  running  4.1  Unix,  with  8  Mbyte  memory,  connected  to  3Mbit/second 
Fxperimental  llthcrnet.  Owned  by  the  Robotics  group  of  tlie  Stanford  Computer  Science 
DcpaitmenL 

Carmel  A  Vax-1  1/750  running  4.1  Unix  during  experiments,  with  2  Mbyte  memory,  connected  to 
3Mbit/sccond  Experimental  Eihemet  Owned  by  the  Stanford  Computer  Science 
Department  for  file  server  development 

Coyote  A  Vax-1  1/750  running  4.2  Unix,  with  2  Mbyte  memory,  connected  to  both  3Mbit/second 
Fxperimental  Ethernet  and  lOMbit/second  Hthernet  Owned  by  the  Robotics  group  of  the 
Stanford  Computer  Science  Department 

Gregorio  A  Vax-1  1/750  running  4.2  Unix,  with  5  Mbyte  memory,  connected  to  both  3Mbit/sccond 
Fxperimental  Ethernet  and  lOMbit/second  Ethernet.  Owned  by  the  Distributed  Systems 
Group,  and  used  for  Vax  operating  system  support  both  the  Vax  V  kernel  poit  and  Unix. 

Pescadcro  A  Vax-1  1/750  running  4.2  Unix,  with  6  Mbyte  memory,  connected  to  both  3Mbit/sccond 
Fjcperimental  Ethernet  and  lOMbit/second  ELthernct  Owned  by  the  Distributed  Systems 
Group,  and  used  as  the  primary  file  server  for  V-System  development 

ISI-A  A  Vax-11/780  running  4.1  Unix,  with  4  Mbyte  memory,  connected  to  the  Arpanet, 
located  in  the  Information  Science  Institute  in  Marina  del  Rey,  California,  about  500  miles 
south  of  Stanford.  Used  for  InterUsp  support 

ISI-H  A  Vax-1  1/750  running  4.2  Unix,  with  2  Mbyte  memory,  connected  to  the  Arpanet,  also 
ItKated  in  tlie  Information  Science  Institute.  Used  for  Unix  development 

Camelot  A  Vax-1  1/780  running  4.2  Unix,  with  4  Mbyte  memory,  connected  to  3Mbit/second 
Experimental  Ethernet.  Itxated  in  the  Center  for  Educational  Research  at  Stanford,  and 
operated  by  the  I  -ow  Overhead  Timesharing  System  (LOTS). 

Parc-C  A  Vax-1  1/785  running  4.2  Unix,  with  8  Mbyte  memory,  connected  to  tlie  Arpanet. 
Located  in  and  owned  by  the  Xerox  Palo  Alto  Research  Center.  Used  as  a  mail  gateway. 


'ITic  ncxi  column  gives  the  protocols  used  in  the  experiments.  These  were  discussed  at  the  begining  of 
Chapter  6,  and  are  illustrated  in  Figures  6-1  and  6-2. 

Local  The  application  runs  on  the  same  workstation  that  is  used  for  display.  Communication  is  by 
local  V  kernel  messages. 

Vax-ikp  'ITie  V-System  I/O  protocol,  using  a  message  protocol  implemented  directly  above  the  data-link 
layer  of  Hthernct.  The  application  runs  on  a  Vax  Unix  system  and  communicates  via  pipes  to  a 
Unix  program  that  simulates  a  V-kcrncl  by  sending  kernel  packets  on  the  Ethernet 

SUN-IKP  Ihe  application  runs  on  another  workstation,  and  sends  V  messages  directly  using  tlic  Inter- 
Kernel  Protocol. 

Pup  'ITie  PUP  Byte  Stream  Protocol  on  a  directly  connected  Ethernet 

PUKiw  The  PUP  Byte  Stream  Protocol  through  one  or  more  gateways  to  another  Ethernet 

IP  Internet  Protocol  on  a  directly  connected  Ethernet 

IPGW  Internet  Protocol  through  one  or  more  gateways. 

A-IP  Internet  Protocol,  over  an  Ethernet  to  a  PDP-11/23  acting  as  a  gateway  to  the  ARPANET. 

nnnn  A  four  digit  number,  one  of  1200.'  2400, 4800,  or  9600,  refers  to  die  baud  rate  of  a  Vax  terminal 

port  that  was  attached  to  an  RS-232  port  on  the  workstation.  A  simple  V-System  program 
allowed  normal  UNIX  terminal  sessions  on  this  terminal  port  > 


D.1  Text  Benchmark 

The  text  benchmark  was  primarily  a  program  called  ttime,  originally  written  by  Peter  Eichenberger.  This 
program  simply  printed  characters  as  quickly  as  possible  until  stopped  by  an  interrupt  or  for  a  given  amount 
of  time  (two  minutes  was  the  time  used  in  these  experiments).  The  columns  arc:  workstation  type,  server 
host,  protocol,  and  character  rate.  All  numbers  are  given  as  characters  per  second  through  all  layers  of 
software  including  the  terminal  emulator,  except  in  tlic  ItKal  case  where  the  rates  arc  broken  down  into  draw 
and  construction  times.  For  tlicsc  experiments,  which  were  done  only  with  the  V  protocols,  an  option  of  tlie 
vectime  program  was  used. 
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D.2  Vector  Graphics  Benchmark 

'Ilic  vectime  program  was  used  to  test  simple  vector  graphics  performance.  The  columns  in  the  results 
below  are:  workstation  type,  server  host,  protocol,  test  name,  and  vector  rate.  All  numbers  are  in  vectors  per 
second.  The  program  drew  a  fully-connect  36-agon,  and  was  based  on  a  similar  program  written  by  Professor 
Vaughan  Pratt.  1  he  calculations  for  die  points  of  the  polygon  were  done  once  before  timing  began.  For  the 
Ikttch  test  tile  polyg*)n  was  erased  and  displayed  ten  times,  with  the  results  computed  over  all  ten  trials.  The 
benchmark  program  reported  tlie  standard  deviation  for  the  trials.  Runs  witli  large  deviations  were  repeated 
on  tlie  assumption  that  transient  effects  such  as  incoming  computer  mail  or  other  background  activity  caused 
these  anomalous  results. 

For  the  Incremental  test  (noted  below  as  “Add”) each  AddltemcdW  was  preceded  by  an  EditSytnbolcdW  and 
followed  by  an  EndSymbol  call,  to  measure  the  number  of  transactions  per  second.  Since  one  run  of  the 
Incremental  test  typically  took  several  minutes,  these  were  only  repeated  once.  All  experiments  were 
performed  when  timesharing  load  was  low.  Ilie  last  column  gives  the  month  and  year  the  measurements 
were  taken. 
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D.3  Structured  Graphics  Benchmark 


The  struct  ime  program  was  designed  to  test  the  effect  of  structure.  T!iC  benchmark  drew  an  array  of  30 
NMOS  inverters,  each  consisting  of  26  rectangles,  for  a  total  of  780  rectangles,  'llic  resulting  image  was  about 
400  pixels  on  a  side.  Hach  rectangle  was  filled  with  one  of  four  stipple  patterns,  each  representing  one  of  the 
NMOS  process  layers.  In  die  batch  test,  each  of  the  780  rectangles  was  added  to  the  SDK.  resulting  in  a  single 
level,  unstrucuircd  symbol.  I'he  incremental  test  also  used  a  single-level  unstructured  symbol,  with  each  of 
the  780  rectangles  displayed  as  it  was  added. 

In  the  structure  test,  a  “contact  cut"  symbol  was  defined  which  consisted  of  tltree  rectangles,  llien  an 
“inverter”  symbol  was  defined  with  two  calls  to  the  conuict  cut  symbol  and  20  other  rectangles.  30  instances 
of  the  inverter  symbol  were  then  added  to  tlic  top-level  symbol,  resulting  in  a  three-level  display  file.  Thus  a 
total  of  23  primitive  items  and  32  calls  were  added  to  the  SI3F.  for  a  total  of  SS  items.  All  numbers  arc  in 
rectangles  per  second.  Note  that  the  structure  create  rate  might  be  considered  unfairly  low.  ITie  benchmark 
divided  the  total  time  for  creation  by  the  number  of  primitives  added,  in  this  case  23.  To  obtain  the  rate 
including  symbols  calls,  multiply  this  rate  by  55/23  or  about  2.4.  The  last  column  gives  tlic  month  and  year 
the  measurements  were  taken. 
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Table  l>3:  Detailed  structured  graphics  results 


D.4  Illustration  Data 


These  tests  were  performed  on  a  local  lOMhz  workstation  with  the  Sun-1  frame  buffer.  This  table  lists  the 
number  of  items,  time  for  display  in  milliseconds,  the  re.sulting  rate  (including  both  creation  and  display)  in 
items  per  second,  the  memory  that  would  be  needed  to  store  the  bitmap  (in  thousands  of  bytes),  and  and  the 
memory  used  in  the  SDF  (also  in  thousands  of  bytes).  These  experiments  were  performed  in  October  of 
1984. 
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Tabic  I>4:  Detailed  illustration  data 
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